IEEE 754 conformance in Python

[Tim Peters]

[CY Jair]
> 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:

C:\Code\python\dist\src\PCbuild>python
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
'3'
>>>

Most (but not all) flavors of Unix produce '2' there.  Same thing if you
write the test in C.