[Python-Dev] Shorter float repr in Python 3.1?

[Mark Dickinson]

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