[Python-Dev] Shorter float repr in Python 3.1? (original) (raw)

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

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

More information about the Python-Dev mailing list