Message67194
Okay; so this is definitely not a Python bug---it's a well-known
and well-documented problem with IA32 floating-point. And I accept
that it's really not Python's responsibility to document this, either.
Nevertheless, it was a surprise to me when my (supposedly IEEE 754
compliant) Pentium 4 box produced this. I probably shouldn't have
been surprised. I'm aware of issues with 80-bit extended precision when
programming in C, but naively expected that Python would be largely
immune from these, since it's always going to force intermediate results
from (80-bit) floating-point registers into (64-bit) memory slots.
There's an excellent recent article by David Monniaux, "The pitfalls of
verifying floating-point computations.", that's available online at
http://hal.archives-ouvertes.fr/hal-00128124
that explains exactly what's going on here (it's a case of double-
rounding, as described in section 3.1.2 of that paper).
Do you think a documentation patch that added this reference, along with
the oft-quoted "What Every Computer Scientist Should Know About
Floating-Point Arithmetic" by David Goldberg, to Appendix B of the
tutorial would be acceptable?
One other thing that's worth mentioning: on Pentium 4 and later, the
gcc flags "-mfpmath=sse -msse2" appear to fix the problem, by forcing
gcc to use the SSE floating-point unit instead of the x87-derived one.
In any case, I guess this report should be closed as 'invalid', but I
hope that at least others who encounter this problem manage to find this
bug report. |
|
Date |
User |
Action |
Args |
2008-05-22 15:02:03 | mark.dickinson | set | spambayes_score: 0.00105006 -> 0.0010500585 recipients:
+ mark.dickinson, loewis |
2008-05-22 15:02:00 | mark.dickinson | set | spambayes_score: 0.00105006 -> 0.00105006 messageid: <1211468520.37.0.530631894493.issue2937@psf.upfronthosting.co.za> |
2008-05-22 15:01:59 | mark.dickinson | link | issue2937 messages |
2008-05-22 15:01:54 | mark.dickinson | create | |
|