[Python-Dev] Python 2.6/3.0, IEEE 754 floating point semantics and S60 (original) (raw)

Torne Wuff torne-pythondev at wolfpuppy.org.uk
Thu Nov 27 19:31:39 CET 2008

On Thu, Nov 27 08 at 3:58:43PM +0100, Christian Heimes wrote:

A while ago I contacted Jukka Laurila from the Nokia developer board about IEEE 754 support on S60 phones. The information from Jukka may be useful for future reference.

OK, I want to weigh in here, but first I need a lil disclaimer: I'm a Symbian core developer and theoretically in a position to fix this kind of thing, but I am not speaking in an official capacity and nothing here should be taken to represent Symbian or Nokia etc etc blah blah :)

Also, I'm not quite a floating point expert, but have had to deal with various issues in the past, and wrote some of our hardware floating point support code, so the below is my best guesses.

We've been battling with some float problems recently as well in the course of our 2.5 core porting. The principal problem has been imprecise floating point formatting/parsing routines which lead to the unfortunate case of not being able to roundtrip a Python float to string and back bit-exactly. I've been trying to get to the bottom of that problem and so far it seems like the root cause is a poorly written C library.

The formatting/parsing routines for floats are not imprecise, they just don't print enough digits to make roundtripping work. We only print 15 digits, because that's the most digits we can guarantee to calculate accurately. Working out the 16th and 17th digits requires that you have a higher-than-double-precision intermediate representation, which is not guaranteed, see below. So, I'd like to suggest that "poorly written" is not true. :)

Though on the other hand, no one from Symbian is yet to confirm to me that the software-emulated floating point routines correspond to anything like IEEE 754. Most S60 devices lack floating point hardware.

I think I might've actually been the one to receive these queries.. I did try to explain. We should be IEEE 754 compliant. We have a range of tests which attempt to prove this. If someone has a case demonstrating otherwise please let me know and I'll raise an issue. :)

Floating point hardware makes it worse, though, not better: ARM's VFP floating point hardware has only single and double precision. Our software implementation uses 64 bit mantissas for intermediates, which is indeed enough to print 17 digits correctly, but on platforms where the VFP is enabled globally, there is no such higher intermediate precision and were we to try and print 17 digits some of them would be wrong.

So, I'm not sure that it's actually possible for us to do better; maybe it is, maybe not.

The best guess is that the floating point support is IEEE 754'ish, with imprecise formatting and parsing routines in the standard library.

IEEE 754 doesn't include string formatting or parsing as far as I know, so I think this is irrelevant to whether we are compliant :)

Does any standard actually promise that roundtripping will work, or is it just assumed?

-- Torne Wuff torne at wolfpuppy.org.uk

More information about the Python-Dev mailing list