IEEE 754 conformance in Python
tim_one at email.msn.com
Wed Mar 7 03:22:21 CET 2001
> Python's floating-point numbers representations are done by C
> library, with 17 significant decimal digits preserved by the "%.17g"
> format in floatobject.c file.
All of Python's floating-point behavior is inherited from the platform C
compiler and libraries.
> It is advertised to be conformant to IEEE 754 double precision standard.
Unclear what "it" means here. CPython does not promise anything wrt 754.
> Java is advertised as fully conformant to IEEE 754 by Sun. However, when I
> compare the two, I'm getting a little bit doubtful.
Note that string<->double behavior isn't fully specified by the 754 standard
(I/O conversions are unique among the operations covered by 754 in this way:
a conforming implementation need not round them properly).
> One more thing that makes me wonder is the way Python does rounding on
> floating-point numbers. In the IEEE standard, when rounding a "halfway"
> result to the nearest floating-point number, it picks the one
> that is even.
By default, yes, although it also depends on the rounding mode in effect.
> But Python's way of "%.17g" doesn't seem to work that way.
CPython's %.17g behavior is inherited from the platform C sprintf %.17g
behavior. It can and does vary across platforms; e.g., "add a half and
chop" is normal under Windows:
Python 2.1b1 (#11, Mar 3 2001, 05:56:55) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> "%.0g" % 2.5
Most (but not all) flavors of Unix produce '2' there. Same thing if you
write the test in C.
More information about the Python-list