[Python-Dev] Numerical robustness, IEEE etc. (original) (raw)

Nick Maclaren nmm1 at cus.cam.ac.uk
Fri Jun 23 14:38:14 CEST 2006

To the moderator: this is getting ridiculous.

jacobs at bioinformed.com wrote:

> >Unfortunately, that doesn't help, because it is not where the issues > >are. What I don't know is how much you know about numerical models, > >IEEE 754 in particular, and C99. You weren't active on the SC22WG14 > >reflector, but there were some lurkers. Hand wave, hand wave, hand wave. Many of us here aren't stupid and have more than passing experience with numerical issues, even if we haven't been "active on SC22WG14". Let's stop with the high-level pissing contest and lay out a clear technical description of exactly what has your knickers in a twist, how it hurts Python, and how we can all work together to make the pain go away.

SC22WG14 is the ISO committee that handles C standardisation. One of the reasons that the UK voted "no" was because the C99 standard was seriously incomprehensible in many areas to anyone who had not been active on the reflector. If you think that I can summarise a blazing row that went on for over 5 years and produced over a million lines of technical argument alone in a "clear technical description", you have an exaggerated idea of my abilities.

I have a good many documents that I could post, but they would not help. Some of them could be said to be "clear technical descriptions" but most of them were written for other audiences, and assume those audiences' backgrounds. I recommend starting by reading the comments in floatobject.c and mathmodule.c and then looking up the sections of the C89 and C99 standards that are referenced by them.

A good place to start: You mentioned earlier that there where some nonsensical things in floatobject.c. Can you list some of the most serious of these?

Well, try the following for a start:

Python 2.4.2 (#1, May 2 2006, 08:28:01) [GCC 4.1.0 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information.

a = "NaN" b = float(a) c = int(b) d = (b == b) print a, b, c, d NaN nan 0 False

Python 2.3.3 (#1, Feb 18 2004, 11:58:04) [GCC 2.8.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information.

a = "NaN" b = float(a) c = int(b) d = (b == b) print a, b, c, d NaN NaN 0 True

That demonstrates that the error state is lost by converting to int, and that NaN testing isn't reliable.

Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1 at cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

More information about the Python-Dev mailing list