Hacker News Reader

One important detail: "digit" when talking about sdigit & ob_digit are not base-10 digits, but base 10000 for 32-bit CPython and base 1000000000 for 64-bit CPython!

That means PY_SIZE(-15) is -1, not -2! And the maximum representable integer in Python should be closer to 10000 * (sys.maxsize / 2) for 32-bit and 1000000000 * (sys.maxsize / 4) for 64-bit.

View on HN

I need to correct myself: on my 64 bit system, given M = ((1 << (30 * N)) - 1, M is the largest integer such that sys.getsizeof(M) = 24 + 4 * N.

Assuming I made no further mistakes, sys.getsizeof(I) <= sys.maxsize for any I, which implies that the largest representable integer in Python is (1 << (30 * Nmax)) - 1, where Nmax = (sys.maxsize - 24) // 4 = 2305843009213693945, so the actual maximum integer is (1 << 69175290276410818350) - 1 which is approximately 10 ** 2.082383733196259e+19 (for comparison, 10 ** sys.maxsize is approximately 10 ** 9.223372036854776e+18)

Thank you for your clarification/correction !

I'll update the article.

Do they really store bignums as base-(10^x) chunks instead of base-(2^x) chunks? That wastes quite a lot of memory, but for what reason? It makes printing it out slightly easier?

Reply on news.ycombinator.com