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

[Torne Wuff]

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