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 MrJean1, mark.dickinson, rhettinger, tim.peters
Date 2008-07-30.22:26:24
SpamBayes Score 3.21021e-05
Marked as misclassified No
Message-id <1217456786.27.0.804834683693.issue2819@psf.upfronthosting.co.za>
In-reply-to
Content
Mark, I don't currently have a machine with SVN and a compiler
installed, so can't play with patches.  I just want to note here that,
if you're concerned about speed, it would probably pay to eliminate all
library calls except one to frexp().  fmod() in particular is typically
way too expensive, taking time proportional to the difference between
its inputs' exponents (it emulates "long division" one bit at a time). 
While float->integer conversion is also "too expensive" on Pentium
chips, multiply-and-convert-to-integer is probably a substantially
cheaper way to extract bits from the mantissa frexp() delivers; note
that this is how the Cookbook lsum() function gets bits, although it
gets all 53 bits in one gulp while in C you'd probably want to get,
e.g., 30 bits at a time.

Something that's surprised me for decades is how slow platform ldexp()
functions are too, given how little they do.  Whenever you have a fixed
offset E you'd like to add to an exponent, it's almost certainly very
much faster to multiply by 2.0**E (when that's a compile-time constant)
than to call ldexp(whatever, E).
History
Date User Action Args
2008-07-30 22:26:26tim.peterssetrecipients: + tim.peters, rhettinger, mark.dickinson, MrJean1
2008-07-30 22:26:26tim.peterssetmessageid: <1217456786.27.0.804834683693.issue2819@psf.upfronthosting.co.za>
2008-07-30 22:26:25tim.peterslinkissue2819 messages
2008-07-30 22:26:24tim.peterscreate