Message71118
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. |
|
Date |
User |
Action |
Args |
2008-08-14 11:10:16 | mark.dickinson | set | recipients:
+ mark.dickinson, tim.peters, rhettinger, terry.reedy, MrJean1 |
2008-08-14 11:10:15 | mark.dickinson | set | messageid: <1218712215.3.0.105759119655.issue2819@psf.upfronthosting.co.za> |
2008-08-14 11:10:12 | mark.dickinson | link | issue2819 messages |
2008-08-14 11:10:11 | mark.dickinson | create | |
|