Mark Dickinson <[EMAIL PROTECTED]> added the comment: 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. Added file: http://bugs.python.org/file11108/fsum11.patch _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2819> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
