On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily <n...@acm.org> wrote: > Ned Deily <n...@acm.org> wrote: >> Eric Smith <e...@trueblade.com> wrote: >> > Before then, if anyone could build and test the py3k-short-float-repr >> > branch on any of the following machines, that would be great: >> > >> [...] >> > Something bigendian, like a G4 Mac >> >> I'll crank up some OS X installer builds and run them on G3 and G4 Macs >> vs 32-/64- Intel. Any tests of interest beyond the default regttest.py?
Ned, many thanks for doing this! > Then I tried a couple of random floats: > > Python 3.1a2+ (py3k-short-float-repr, Apr 13 2009, 20:55:35) > [GCC 4.0.1 (Apple Inc. build 5490)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> 3.1 > -9.255965342383856e+61 >>>> 1. > ^C > Terminated <-- kill needed Cool! I suspect endianness issues. As evidence, I present: >>> list(struct.pack('<d', 3.1)) [205, 204, 204, 204, 204, 204, 8, 64] >>> list(struct.pack('<d', -9.255965342383856e+61)) [204, 204, 8, 64, 205, 204, 204, 204] I'm guessing that the problem is that when you build on Intel, the configure script detects a little-endian machine, and Gay's code then uses the little-endian defines throughout, both for PPC and Intel. I don't know any sensible way to fix this. But I'd expect that there are already similar issues with a 'fat' build of py3k on OS X. After all, there's already a 'WORDS_BIGENDIAN' in pyconfig.h.in. I don't know where this is used. Mark _______________________________________________ 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