[Python-Dev] Re: marshal / unmarshal
mwh at python.net
Mon Apr 11 18:01:49 CEST 2005
Tim Peters <tim.peters at gmail.com> 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?
> Not anymore -- hasn't been part of my job, or a hobby, for over a
> decade. There were differences a decade+ ago. All NaNs have all
> exponent bits set, and at least one mantissa bit set, and every bit
> pattern of that form represents a NaN. That's all the standard says.
> The most popular way to distinguish quiet from signaling NaNs keyed
> off the most-significant mantissa bit: set for a qNaN, clear for an
> sNaN. It's possible that all 754 HW does that now.
OK, so the worst that could happen here is that moving marshal data
from one box to another could turn one sort of NaN into another? This
doesn't seem very bad.
>> I'd find struggling to care about that pretty hard.
> Me too.
>>>> The question, of course, is how to tell.
>>> Store a few small doubles at module initialization time and stare at
>> ./configure time, surely?
> Unsure. Not all Python platforms _have_ "./configure time".
But they all have pyconfig.h.
> Module initialization code is harder to screw up for that reason
> (the code is in an obvious place then, self-contained, and doesn't
> require any relevant knowledge of any platform porter unless/until
> it breaks).
Well, sure, but false negatives here are not a big deal here.
>>> 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?
> No. Pemberton's enquire.c contains enough code to do it.
Yikes! And much else besides.
> Given how few distinct architectures still exist, it's probably
> enough to store just double x = 1.5 and stare at it.
Something along these lines:
double x = 1.5;
is_big_endian_ieee_double = sizeof(double) == 8 && \
memcmp((char*)&x, "\077\370\000\000\000\000\000\000", 8);
[me being obscure]
> I think I'm still missing your intent here. If you're asking whether
> Python can blindly assume that 745 is in use, I'd say that's
> undesirable but defensible if necessary.
Yes, that's what I was asking, in a rather obscure way.
Strangely enough I saw just such a beast at the grocery store
last night. Starbucks sells Javachip. (It's ice cream, but that
shouldn't be an obstacle for the Java marketing people.)
-- Jeremy Hylton, 29 Apr 1997
More information about the Python-Dev