[mwh] > OTOH, the implementation has this comment: > > /*---------------------------------------------------------------------------- > * _PyFloat_{Pack,Unpack}{4,8}. See floatobject.h. > * > * TODO: On platforms that use the standard IEEE-754 single and double > * formats natively, these routines could simply copy the bytes. > */ > > Doing that would fix these problems, surely?[1]
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. 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. > [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. > The question, of course, is how to tell. Store a few small doubles at module initialization time and stare at 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. ... > [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. _______________________________________________ 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