[Python-Dev] Shorter float repr in Python 3.1?
dickinsm at gmail.com
Tue Apr 14 12:31:21 CEST 2009
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily <nad at acm.org> wrote:
> Ned Deily <nad at acm.org> wrote:
>> Eric Smith <eric at 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.
> 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.
More information about the Python-Dev