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 MrJean1, mark.dickinson, rhettinger, terry.reedy, tim.peters
Date 2008-08-14.11:10:01
SpamBayes Score 2.27722e-07
Marked as misclassified No
Message-id <1218712215.3.0.105759119655.issue2819@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a patch, in final form, that replaces fsum with an lsum-based
implementation.  In brief, the accumulated sum-so-far is represented in
the form

  huge_integer * 2**(smallest_possible_exponent)

and the huge_integer is stored in base 2**30, with a signed-digit representation (digits 
in the range [-2**29, 2**29).

What are the chances of getting this in before next week's beta?

I did toy with a base 2**52 version, with digits stored as doubles.  It's attractive for 
a couple of reasons: (1) each 53-bit double straddles exactly two digits, which makes 
the inner loop more predictable and removes some branches, and (2) one can make some 
optimizations (e.g. being sloppy about transferring single-bit carries to the next digit 
up) based on the assumption that the input is unlikely to have more than 2**51 summands.  The result was slightly faster on OS X, and slower on Linux;  the final rounding code 
also became a little more complicated (as a result of not being able to do bit 
operations on a double easily), and making sure that things work for non IEEE doubles is 
a bit of a pain.  So in the end I abandoned this approach.
History
Date User Action Args
2008-08-14 11:10:16mark.dickinsonsetrecipients: + mark.dickinson, tim.peters, rhettinger, terry.reedy, MrJean1
2008-08-14 11:10:15mark.dickinsonsetmessageid: <1218712215.3.0.105759119655.issue2819@psf.upfronthosting.co.za>
2008-08-14 11:10:12mark.dickinsonlinkissue2819 messages
2008-08-14 11:10:11mark.dickinsoncreate