This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients PedanticHacker, Stefan Pochmann, mark.dickinson, mcognetta, rhettinger, serhiy.storchaka, tim.peters
Date 2021-12-29.22:34:54
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1640817294.7.0.891408467189.issue37295@roundup.psfhosted.org>
In-reply-to
Content
A practical caution about this in comb_with_side_limits.py:

    Pmax = 25           # 25         41
    Fmax = Pmax

It's true then that 25! == F[25] << S[25], but that's so in Python. The result has 84 bits, so 64-bit C arithmetic isn't enough.

That's apparently why mathmodule.c's static SmallFactorials[] table ends at 20 (the largest n such that n! fits in 64 bits).

(Well, actually, it ends at 12 on Windows, where sizeof(long) is 4, even on "modern" 64-bit boxes)

I would, of course, use uint64_t for these things - "long" and "long long" are nuisances, and not even attractive ones ;-) While support (both software and HW) for 64-bit ints progressed steadily in the 32-bit era, the same does not appear to be true of 128-bit ints in the 64-bit era. Looks to me like 64-bit ints will become as much a universal HW truth as, say, 2's-complement, and byte addresses, have become.
History
Date User Action Args
2021-12-29 22:34:54tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, serhiy.storchaka, PedanticHacker, mcognetta, Stefan Pochmann
2021-12-29 22:34:54tim.peterssetmessageid: <1640817294.7.0.891408467189.issue37295@roundup.psfhosted.org>
2021-12-29 22:34:54tim.peterslinkissue37295 messages
2021-12-29 22:34:54tim.peterscreate