Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect rounding in floating-point operations with gcc/x87 #47186

mdickinson opened this issue May 21, 2008 · 4 comments

Incorrect rounding in floating-point operations with gcc/x87 #47186

mdickinson opened this issue May 21, 2008 · 4 comments
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error


Copy link

BPO 2937
Nosy @loewis, @mdickinson

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2008-12-05.21:32:58.705>
created_at = <Date 2008-05-21.20:36:56.457>
labels = ['interpreter-core', 'type-bug', 'invalid']
title = 'Incorrect rounding in floating-point operations with gcc/x87'
updated_at = <Date 2008-12-05.21:32:58.704>
user = '' fields:

activity = <Date 2008-12-05.21:32:58.704>
actor = 'mark.dickinson'
assignee = 'none'
closed = True
closed_date = <Date 2008-12-05.21:32:58.705>
closer = 'mark.dickinson'
components = ['Interpreter Core']
creation = <Date 2008-05-21.20:36:56.457>
creator = 'mark.dickinson'
dependencies = []
files = []
hgrepos = []
issue_num = 2937
keywords = []
message_count = 4.0
messages = ['67174', '67180', '67194', '77073']
nosy_count = 2.0
nosy_names = ['loewis', 'mark.dickinson']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = ''
versions = ['Python 2.6', 'Python 3.0']

Copy link
Member Author

On some older Intel 32-bit hardware, under Linux, floating-point
operations don't always give correctly rounded results. Here's an
example involving addition, on SuSE Linux 10.2/Xeon.

Python 2.6a3+ (trunk:63521, May 21 2008, 15:40:39) 
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 1e16 + 2.999
>>> 1e16 + 2.9999

The second result should really be 1e16+2., not 1e16+4. This appears to
be related to this GCC issue:

Various fixes are possible. One possible fix is to add the -ffloat-
store flag to the gcc options. Another is to use the information in
fpu_control.h, if available, to set the precision control. Yet another
is to sprinkle some 'volatile' modifiers throughout floatobject.c.

It's not clear to me that this *should* be fixed, but I think the
problem should at least be documented. Hence this bug report.

@mdickinson mdickinson added interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error labels May 21, 2008
Copy link

loewis mannequin commented May 22, 2008

Python (the language) makes no guarantee itself on what the precise
semantics of floating-point operations is. This is documented in

"These represent machine-level double precision floating point numbers.
You are at the mercy of the underlying machine architecture (and C or
Java implementation) for the accepted range and handling of overflow."

If you want to, one could add ", precision" in the sentence; I think it
is fine as it stands.

Copy link
Member Author

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

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.

Copy link
Member Author

Closing as invalid.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
None yet

No branches or pull requests

1 participant