Tim Peters <[EMAIL PROTECTED]> 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 _______________________________________________ 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