NaN again - and IEEE arithmatics
Huaiyu Zhu
hzhu at rocket.knowledgetrack.com
Mon May 15 15:30:52 EDT 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