Tim Peters <[EMAIL PROTECTED]> writes:
> The 754 standard doesn't say anything about how the difference between
> signaling and quiet NaNs is represented. So it's possible that a qNaN
> on one box would "look like" an sNaN on a different box, and vice
> versa. But since most people run with all FPU traps disabled, and
> Python doesn't expose a way to read the FPU status flags, they
> couldn't tell the difference.
OK. Do you have any intuition as to whether 754 implementations
actually *do* differ on this point?
> Copying bytes works perfectly for all other cases (signed zeroes,
> non-zero finites, infinities), because their representations are
> wholly defined, although it's possible that a subnormal on one box
> will be treated like a zero (with the same sign) on a
> partially-conforming box.
I'd find struggling to care about that pretty hard.
>> [1] I'm slighyly worried about oddball systems that do insane things
>> with the FPU by default -- but don't think the mooted change would
>> make things any worse.
>
> Sorry, don't know what that means.
Neither do I, now. Oh well <wink>.
>> The question, of course, is how to tell.
>
> Store a few small doubles at module initialization time and stare at
./configure time, surely?
> their bits. That's enough to settle whether a 754 format is in use,
> and, if it is, whether it's big-endian or little-endian.
Do you have a pointer to code that does this? Googling around the
subject appears to turn up lots of Python stuff...
>> [2] Exaggeration, I realize -- but how many non 754 systems are out
>> there? How many will see Python 2.5?
>
> No idea here. The existing pack routines strive to do a good job of
> _creating_ an IEEE-754-format representation regardless of platform
> representation. I assume that code would still be present, so
> "oddball" platforms would be left no worse off than they are now.
Well, yes, given the above. The text this footnote was attached to
was asking if just assuming 754 float formats would inconvenience
anyone.
Cheers,
mwh
--
I don't have any special knowledge of all this. In fact, I made all
the above up, in the hope that it corresponds to reality.
-- Mark Carroll, ucam.chat
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
