NaN again - and IEEE arithmatics

Huaiyu Zhu hzhu at rocket.knowledgetrack.com
Mon May 15 21:30:52 CEST 2000


On Sat, 13 May 2000 00:56:32 -0400, Tim Peters <tim_one at email.msn.com> wrote:

>Different machine sounds more plausible.  Python itself knows nothing about
>NaNs, and all visible behavior wrt them is a platform-dependent accident.
>
>THere's nothing you can do that's guaranteed to work.  Here's a way to make
>a NaN that's quite *likely* to work on any IEEE-754 platform, though:
>
>>>> Inf = 1e300**2
>>>> NaN = Inf - Inf
>>>> NaN
>-1.#IND
>>>> Inf
>1.#INF
>>>>
>
>Since that was a Windows session, that's how Microsoft happens to spell NaN
>and infinity these days.
>

Thanks a lot.  It works on both:

RedHat 6.1 egcs-2.91.66  Python 1.5.2 -> nan
Solaris 2.7 gcc 2.95.2 Python 1.6a2   -> NaN

>> So why isn't there a predefined class or object for NaN?
>
>Basically because IEEE-754 is primarily a hardware standard.  The things it
>defines may as well not exist if your *software* doesn't know about them.
>In Python's case, Python is implemented in C, and it's C that provides no
>portable way to get at this stuff.  So Python can't either, at least not
>without a huge pile of #ifdef's, one for each platform, and enough different
>people volunteering with the right combination of platform + 754 expertise
>to write all that crap.
>
>The next iteration of the C standard is supposed to address this.  Then it
>will be much easier to address it in Python too.  In the meantime, you're
>really on your own with this stuff, be it from Python, Perl, C, C++,
>Fortran, ...
>

In the interim it might be worthwhile to implement temporary standard Inf
and NaN objects for a few "popular" platforms like Solaris, NT and Linux:

1. It helps to standardize the name, useful for dumping or loading numbers.
   It would be easy to change when the "true standard" arrives in the future
   then would a hundred differently named hacks.
2. For users of other OSes it provides working examples of how such things
   are supposed to be done so they can implemente them in a more or less
   standard way.

In any case I can live happily with the names nan and NaN, as I'm not
affected by how MS changes names of things.

-- 
Huaiyu Zhu                               hzhu at knowledgetrack.com



More information about the Python-list mailing list