[Python-Dev] Re: marshal / unmarshal

Michael Hudson mwh at python.net
Mon Apr 11 18:01:49 CEST 2005


Tim Peters <tim.peters at gmail.com> writes:

> [Tim]
>>> 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.
>
> [mwh]
>> 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.

[snip details]

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.

[denorms]

>> I'd find struggling to care about that pretty hard.
>
> Me too.

Good.

>>>> 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.

Cheers,
mwh

-- 
  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 mailing list