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 mark.dickinson
Recipients belopolsky, draghuram, mark.dickinson, rhettinger, stutzbach
Date 2010-05-13.21:58:45
SpamBayes Score 0.002482993
Marked as misclassified No
Message-id <1273787928.79.0.0765796576975.issue8692@psf.upfronthosting.co.za>
In-reply-to
Content
> I would expect that for large factorials the performance will be
> determined by the number of long multiplications and the size of
> multiplicands.

Okay, but I don't think we should care about the performance of *really* large factorials for Python.  People who care about every bit of speed in that situation should be using GMP or something similar.  An optimization that only makes a difference for (say) factorial(50000) or higher isn't going to make much difference to most Python users.  Optimizations that speed up, say, factorial(n) for n <= 1000 would seem more valuable.

> The differences between recursive and non-recursive versions are not
> likely to translate well, but the difference (if any) between the
> order of multiplication most likely will.

Perhaps.  But the differences between the various Python versions here are small enough that they could easily be swamped by other factors involved in the Python-to-C translation.

We already have a working C patch here (modulo minor issues), and I'd like to move forward with that patch;  I think this issue discussion is getting a bit side-tracked.

grumpily-yours...
History
Date User Action Args
2010-05-13 21:58:48mark.dickinsonsetrecipients: + mark.dickinson, rhettinger, belopolsky, draghuram, stutzbach
2010-05-13 21:58:48mark.dickinsonsetmessageid: <1273787928.79.0.0765796576975.issue8692@psf.upfronthosting.co.za>
2010-05-13 21:58:46mark.dickinsonlinkissue8692 messages
2010-05-13 21:58:45mark.dickinsoncreate