Mark Dickinson dicki...@gmail.com added the comment:
Closing this. Let's stick with what we have.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2819
___
Changes by Jesús Cea Avión [EMAIL PROTECTED]:
--
nosy: +jcea
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
___
Python-bugs-list mailing list
Changes by STINNER Victor [EMAIL PROTECTED]:
--
nosy: +haypo
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
___
Python-bugs-list mailing list
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
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10988/fsum7.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11008/fsum8.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
Changes by Mark Dickinson [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file11014/fsum10.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
Mark Dickinson [EMAIL PROTECTED] added the comment:
Question: I see math module patch committed, r63542 in May 22. But in
3.0b2, there is no math.fsum and math.sum seems to be a wrapper for
builtin sum. Has this not been forward ported (merged) yet?
I'm pretty sure it *was* merged:
Terry J. Reedy [EMAIL PROTECTED] added the comment:
I'm pretty sure it *was* merged: math.sum should be the full-precision
summation in both recent betas (2.6b2 and 3.0b2). Try comparing
sum([1e100, 1, -1e100, -1]) and math.sum([1e100, 1, -1e100, -1])---they
should produce -1.0 and 0.0
Mark Dickinson [EMAIL PROTECTED] added the comment:
Toned down note in docs (at Raymond's request) in r65366.
While I'd really like to see an lsum-based version go in instead, I
think it's too close to the release to make this change right now.
There was also originally some talk of a complex
Tim Peters [EMAIL PROTECTED] added the comment:
Mark, changing API is something to avoid after beta cycles begin (so,
e.g., it's late in the game to /add/ a new API, like a new method for
complex summation). But there's no particular reason to fear changing
implementation for an API that's
Mark Dickinson [EMAIL PROTECTED] added the comment:
[Tim]
if you're concerned about speed, it would probably pay to eliminate all
library calls except one to frexp().
Indeed it would! Here's a revised patch that avoids use of fmod. Speed is
comparable with the current
version. Here are
Mark Dickinson [EMAIL PROTECTED] added the comment:
Timings on x86/Linux are similar: the lsum-based version is around
10% slower on average, 25% slower in the worst case, and significantly
faster for the msum worst cases.
There's probably still some snot left to optimize out, though. Some
Mark Dickinson [EMAIL PROTECTED] added the comment:
Minor code cleanups, and fixes to special-value handling in r65299
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
___
Mark Dickinson [EMAIL PROTECTED] added the comment:
Renamed math.sum to math.fsum (as previously discussed) in r65308.
I think all that's left now is to add a note to the docs about the
problems on x86.
___
Python tracker [EMAIL PROTECTED]
Mark Dickinson [EMAIL PROTECTED] added the comment:
Added documentation note about x86 problems in r65315.
Jean, Raymond: is it okay to close this issue now?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
Mark Dickinson [EMAIL PROTECTED] added the comment:
Here (fsum8.patch) is a clean version of the alternative fsum algorithm.
I'd like to push for using this in place of the existing algorithm.
Added file: http://bugs.python.org/file11008/fsum8.patch
___
Tim Peters [EMAIL PROTECTED] added the comment:
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().
Mark Dickinson [EMAIL PROTECTED] added the comment:
See r65292 for more updates to the test-suite: I've replaced the Python
version of msum by a version based on lsum in the original ASPN recipe.
___
Python tracker [EMAIL PROTECTED]
Mark Dickinson [EMAIL PROTECTED] added the comment:
Tests related to overflow, special-values, intermediate overflow, and
results at or near the boundary of the floating-point range have been
removed in r65258.
___
Python tracker [EMAIL PROTECTED]
Mark Dickinson [EMAIL PROTECTED] added the comment:
Here's a patch giving an alternative implementation of math.fsum; it's
based on Tim Peter's suggestions, works mostly with integer arithmetic,
and so bypasses problems with double rounding and extended precision
floats.
The patch is
Mark Dickinson [EMAIL PROTECTED] added the comment:
Here's a patch that fixes the problems with math.sum on x86 machines that
aren't using SSE2.
On these machines, the patched version of math.sum does almost the entire
calculation using long doubles instead of doubles. Then in the final
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10406/test_math_sum11.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Jean Brouwers [EMAIL PROTECTED] added the comment:
Here is rev 12 of the mathmodule.c patch. It is the same as rev 11 but
with additional code removed as requested:
- no FLT_RADIX 2 check
- no errno illustration in _do_sum_add2()
- no _do_sum() callback function argument
- no option 'start'
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10408/test_math_sum12.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Jean Brouwers [EMAIL PROTECTED] added the comment:
Here is another, cleaner revision 19 of the same mathmodule.c patch and
the corresponding test_math_sum19.py script.
/Jean Brouwers
Added file: http://bugs.python.org/file10410/mathmodule19.c.2.6a3.diff
__
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10411/test_math_sum19.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Nice work Jean. Marking the patch accepted. Mark please go ahead with
commit.
Once the commit has settled for a couple of days, go ahead with a
separate patch to cover the rest of 754R logic for special values.
After that one
Mark Dickinson [EMAIL PROTECTED] added the comment:
math module patch committed, r63542.
I'm still working on converting the tests to the unittest framework.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
Mark Dickinson [EMAIL PROTECTED] added the comment:
Tests committed in r63543
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Python-bugs-list mailing list
Mark Dickinson [EMAIL PROTECTED] added the comment:
The latest mathmodule patch (file 10371) looks pretty good to me. I
haven't looked at the complex version yet. A few comments:
- for setting _do_sum_pow_2 I think you should use ldexp instead of pow;
there's a much greater chance of pow
Changes by Jean Brouwers [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10364/mathmodule4.c.2.6a3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Jean Brouwers [EMAIL PROTECTED] added the comment:
Attached is the patch for the the mathmodule.c file of Python 2.6a3
containing the C version of the msum() function from Marks's msum4.py
Python implementation.
Please review the C code, in particular the setting of _do_sum_pow_2 for
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10365/mathmodule4.c.2.6a3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10366/test_math_sum4.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Changes by Jean Brouwers [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10366/test_math_sum4.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Changes by Jean Brouwers [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10365/mathmodule4.c.2.6a3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Jean Brouwers [EMAIL PROTECTED] added the comment:
Attached are updated patches for both the mathmodule.c and cmathmodule.c
files for Python 2.6a3 and for the test_math_sum4.py script. Please
ignore the ones posted earlier.
Added file:
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10372/cmathmodule4.c.2.6a3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10373/test_math_sum4.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Jean Brouwers [EMAIL PROTECTED] added the comment:
The tests of the test_math_sum4.py script all pass with the latest math-
and cmathmodule.c files for 4 different builds of Python 2.6a3:
- GNU gcc 4.0.1 on MacOS X 10.4.11 (Intel Core Duo), 32-bit
- GNU gcc 4.1.2 on RHEL 3 update 7 (Opteron),
Mark Dickinson [EMAIL PROTECTED] added the comment:
Okay, just to show it's possible:
Here (msum4.py) is a modified version of Raymond's recipe that deals
correctly with:
(1) intermediate overflows
(2) special values (infs and nans) in the input, and
(3) always gives correctly rounded
Jean Brouwers [EMAIL PROTECTED] added the comment:
I intend to submit a C version of msum4 shortly.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Python-bugs-list
Mark Dickinson [EMAIL PROTECTED] added the comment:
Here's (msum.py) an example in Python of one fairly straightforward way of
dealing with overflow correctly, without needing more than one pass
through the data, and without significant slowdown in the normal case.
(The Python code is
Changes by Jean Brouwers [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file10306/unnamed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Python-bugs-list
Jean Brouwers [EMAIL PROTECTED] added the comment:
Two tests failed with Python 2.6a3 on MacOS X Intel.
Test 11 failed: 9007199254740992.0 vs 9007199254740991.0 expected for
[9007199254740992.0, -0.5, -5.5511151231257827e-17].
Test 12 failed: inf vs 1.7976931348623157e+308 expected for
Mark Dickinson [EMAIL PROTECTED] added the comment:
Test 11 failed: 9007199254740992.0 vs 9007199254740991.0 expected for
[9007199254740992.0, -0.5, -5.5511151231257827e-17].
Yes: that's the lack of correct rounding rearing its ugly head...
Test 12 failed: inf vs 1.7976931348623157e+308
Mark Dickinson [EMAIL PROTECTED] added the comment:
Ensuring correct rounding isn't as onerous as I expected it to be.
crsum.py is a snippet of Python code showing how to add nonadjacent floats
and get the correctly rounded result.
Added file: http://bugs.python.org/file10351/crsum.py
Raymond Hettinger [EMAIL PROTECTED] added the comment:
When you need full precision, the Kahan approach helps but doesn't make
guarantees and can sometimes hurt (it makes some assumptions about the
data). One use case in is computing stats like a mean where many of
the larger magnitude
Jean Brouwers [EMAIL PROTECTED] added the comment:
Mark,
Thank you very much for your comments. Here is my initial response to the
first 3.
(1) Attached is an attempt to address the 1st issue (just the
mathmodule). The macros PyFPE_START_PROTECT/_END_PROTECT have been moved
outside the main
Jean Brouwers [EMAIL PROTECTED] added the comment:
My apologies for the messy post. I replied to the email instead of
posting my response.
/Jean Brouwers
PS) Attached is *an* example of the math_sum() and cmath_sum() functions
using the same, shared function float_sum(). Perhaps, that
Mark Dickinson [EMAIL PROTECTED] added the comment:
One related issue is testing these, how can a NaN and +/-Infinity
float object be created in Python?
In 2.6 and 3.0 (but not 2.5 and older), float('nan'), float('inf') and
float('-inf') should all work reliably across platforms (or at
Jean Brouwers [EMAIL PROTECTED] added the comment:
It turns out, float('nan') creates a Nan and float('[+|-]inf') creates a
[signed] Infinity object. That answers my earlier question.
/Jean Brouwers
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
Jean Brouwers [EMAIL PROTECTED] added the comment:
The current results are quite interesting
math.sum([1e308, 1e308, -1e308])
Traceback (most recent call last):
File stdin, line 1, in module
OverflowError: math range error
math.sum([1e308, -1e308, 1e308])
1e+308
Handling this case would
Jean Brouwers [EMAIL PROTECTED] added the comment:
There may be another reason to use a single summation function. The
summation functions does need (a copy of) the is_error() function from
the math module.
The cmath module has a similar function called math_error() which
slightly different
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Rather keep it in mathmodule.c, not floatobject.c.
We should keep extension code out of the core types.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10286/mathmodule.c.2.6a3.diff
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Changes by Jean Brouwers [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file10287/test_math_sum1.py
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2819
__
___
Raymond Hettinger [EMAIL PROTECTED] added the comment:
This looks pretty good at first glance. Will review more throughly
later this week. It does need docs and unittests.
--
assignee: - rhettinger
__
Tracker [EMAIL PROTECTED]
Mark Dickinson [EMAIL PROTECTED] added the comment:
Some comments/questions:
(1) It seems wasteful to wrap every addition in PyFPE_START/END_PROTECT,
and to check for NaNs and infinities after every addition. I'd wrap the
whole thing in a single PyFPE_START/END_PROTECT, replace _math_sum_add
Mark Dickinson [EMAIL PROTECTED] added the comment:
One more question:
What are the use cases for an exact summation algorithm? That is, in what
situations does one care about exactness rather than simply accuracy? I
know that loss of accuracy is a problem in things like numeric integration
61 matches
Mail list logo
