Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: In article 49e3d34e.8040...@trueblade.com, 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? Thanks! regrtest.py should be enough. Eric. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article nad-d10aa9.19075613042...@news.gmane.org, Ned Deily n...@acm.org wrote: In article 49e3d34e.8040...@trueblade.com, 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? FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. n...@pbg4:/Library/Frameworks/Python.framework/Versions/3.1$ bin/python -S lib/python3.1/test/regrtest.py -s -v test_builtin test_builtin test_abs (test.test_builtin.BuiltinTest) ... ok test_all (test.test_builtin.BuiltinTest) ... ok test_any (test.test_builtin.BuiltinTest) ... ok test_ascii (test.test_builtin.BuiltinTest) ... ok test_bin (test.test_builtin.BuiltinTest) ... ok test_callable (test.test_builtin.BuiltinTest) ... ok test_chr (test.test_builtin.BuiltinTest) ... ok test_cmp (test.test_builtin.BuiltinTest) ... ok test_compile (test.test_builtin.BuiltinTest) ... ok test_delattr (test.test_builtin.BuiltinTest) ... ok test_dir (test.test_builtin.BuiltinTest) ... ok test_divmod (test.test_builtin.BuiltinTest) ... ok test_eval (test.test_builtin.BuiltinTest) ... ok test_exec (test.test_builtin.BuiltinTest) ... ok test_exec_redirected (test.test_builtin.BuiltinTest) ... ok test_filter (test.test_builtin.BuiltinTest) ... ok test_general_eval (test.test_builtin.BuiltinTest) ... ok test_getattr (test.test_builtin.BuiltinTest) ... ok test_hasattr (test.test_builtin.BuiltinTest) ... ok test_hash (test.test_builtin.BuiltinTest) ... ok test_hex (test.test_builtin.BuiltinTest) ... ok test_id (test.test_builtin.BuiltinTest) ... ok test_import (test.test_builtin.BuiltinTest) ... ok test_input (test.test_builtin.BuiltinTest) ... ok test_isinstance (test.test_builtin.BuiltinTest) ... ok test_issubclass (test.test_builtin.BuiltinTest) ... ok test_iter (test.test_builtin.BuiltinTest) ... ok test_len (test.test_builtin.BuiltinTest) ... ok test_map (test.test_builtin.BuiltinTest) ... ok test_max (test.test_builtin.BuiltinTest) ... ok test_min (test.test_builtin.BuiltinTest) ... ok test_neg (test.test_builtin.BuiltinTest) ... ok test_next (test.test_builtin.BuiltinTest) ... ok test_oct (test.test_builtin.BuiltinTest) ... ok test_open (test.test_builtin.BuiltinTest) ... ok test_ord (test.test_builtin.BuiltinTest) ... ok test_pow (test.test_builtin.BuiltinTest) ... ^CTerminated Stepping through some of test_pow from the interactive interpreter: 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. pow(0,0) 1-- OK pow(2,30) 1073741824 -- OK pow(0.,0) ^C^CTerminated -- float argument = python hung in CPU loop, killed 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 The same tests work fine on the intel Mac. Just out of curiosity, I'll try to do the same build on the 10.4 ppc; there are occasionally a few differences noted in the build results. That won't be available until later today. -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Ned Deily wrote: 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? FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. The good news: on 10.5 i386, running the default regrtest, no signficant differences were noted from an installer built from the current main py3k head. Okay, that's awesome. Thanks. Bad news: the same build installed on a G4 running 10.5 hung hard in test_pow of test_builtin; a kill was needed to terminate python. Same results on a G3 running 10.4. Okay, that's less than awesome. But still a huge thanks. 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 I don't suppose it's possible that you could run this under gdb and get a stack trace when it starts looping (assuming that's what's happening)? I think I might have a PPC Mac Mini I can get my hands on, and I'll test there if possible. Eric. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
By the way, a simple native build on OS X 10.4/PPC passed all tests (that we're already failing before). 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 11:37 AM, Mark Dickinson dicki...@gmail.com wrote: By the way, a simple native build on OS X 10.4/PPC passed all tests (that we're already failing before). s/we're/weren't ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson dickinsm at gmail.com writes: 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. It's used e.g. in unicode encoding/decoding, and in the IO lib. If that constant can't take different values depending on the CPU arch, we have a big problem. Regards Antoine. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 9:45 AM, Ned Deily n...@acm.org wrote: FIrst attempt was a fat (32-bit i386 and ppc) build on 10.5 targeted for 10.3 and above; this is the similar to recent python.org OSX installers. What's the proper way to create such a build? I've been trying: ./configure --with-universal-archs=32-bit --enable-framework --enable-universalsdk=/ MACOSX_DEPLOYMENT_TARGET=10.5 but the configure AC_C_BIGENDIAN macro doesn't seem to pick up on the universality: the output from ./configure contains the line: checking whether byte ordering is bigendian... no I was expecting a ... universal instead of ... no. From reading the autoconf manual, it seems as though AC_C_BIGENDIAN knows some magic to make things work for universal builds; it ought to be possible to imitate that magic somehow. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? One thing I don't understand: Is it true that to produce a working universal/fat build of Python, one has to first regenerate configure and pyconfig.h.in using autoconf version = 2.62? If not, then I don't understand how the AC_C_BIGENDIAN autoconf macro can be giving the right results. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson dickinsm at gmail.com writes: Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? If this approach is sane, could it be adopted for all other instances of endianness detection in the py3k code base? Has anyone tested a recent py3k using universal builds? Do all tests pass? ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 5:14 PM, Antoine Pitrou solip...@pitrou.net wrote: If this approach is sane, could it be adopted for all other instances of endianness detection in the py3k code base? I think everything else is fine: float endianness detection (for marshal, pickle, struct) is done at runtime. Integer endianness detection goes via AC_C_BIGENDIAN, which understands universal builds---but only for autoconf = 2.62. Has anyone tested a recent py3k using universal builds? Do all tests pass? Do you know the right way to create a universal build? If so, I'm in a position to test on 32-bit PPC, 32-bit Intel and 64-bit Intel. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson dickinsm at gmail.com writes: Has anyone tested a recent py3k using universal builds? Do all tests pass? Do you know the right way to create a universal build? Not at all, sorry. Regards Antoine. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 5:49 PM, Antoine Pitrou solip...@pitrou.net wrote: Mark Dickinson dickinsm at gmail.com writes: Do you know the right way to create a universal build? Not at all, sorry. No problem :). I might try asking on the pythonmac-sig list. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article loom.20090414t161327-...@post.gmane.org, Antoine Pitrou solip...@pitrou.net wrote: Has anyone tested a recent py3k using universal builds? Do all tests pass? It's done all the time. All of the current released installers (2.5, 2.6, 3.0) are 2-way (i386, ppc) universal and we occasionally test all of the current lines (2.6, trunk, 3.0, 3.1) as 4-way (i386, ppc, x86_64, ppc64), although the ppc64 has had no testing recently. -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article 5c6f2a5d0904140909x417d225ejd845de9c5c780...@mail.gmail.com, Mark Dickinson dicki...@gmail.com wrote: Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? Not looking good. Appears to be same behavior on the G4 with 10.5 (haven't tried the G3 yet). -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article 5c6f2a5d0904140930y7dc7cf4fg496d50fd34f89...@mail.gmail.com, Mark Dickinson dicki...@gmail.com wrote: Do you know the right way to create a universal build? If so, I'm in a position to test on 32-bit PPC, 32-bit Intel and 64-bit Intel. The OSX installer script is in Mac/BuildScript/build-installer.py. For 2-way builds, it essentially does: export MACOSX_DEPLOYMENT_TARGET=10.3 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' and for 4-way: export MACOSX_DEPLOYMENT_TARGET=10.5 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --with-universal-archs='all' --with-computed-gotos OPT='-g -O3' -- Ned Deily, n...@acm.org ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Is it true that to produce a working universal/fat build of Python, one has to first regenerate configure and pyconfig.h.in using autoconf version = 2.62? If not, then I don't understand how the AC_C_BIGENDIAN autoconf macro can be giving the right results. The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact version you look at, things might work differently; in trunk, Include/pymacconfig.h should be used, which does #if defined(__APPLE__) # undef WORDS_BIGENDIAN #ifdef __BIG_ENDIAN__ #define WORDS_BIGENDIAN 1 #endif /* __BIG_ENDIAN */ #endif Earlier versions included that ifdef block directly in pyconfig.h.in. In case it isn't clear how this works: GCC predefines __BIG_ENDIAN__ on PPC but not on x86; for universal binaries, two (or more) separate preprocessor (and compiler runs) are done. HTH, Martin ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
If this approach is sane, could it be adopted for all other instances of endianness detection in the py3k code base? Don't worry - the approach that we already take is already sane, so no further changes are needed. Regards, Martin ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 6:55 PM, Martin v. Löwis mar...@v.loewis.de wrote: The outcome of AC_C_BIGENDIAN isn't used on OSX. Depending on the exact version you look at, things might work differently; in trunk, Include/pymacconfig.h should be used [...] Many thanks---that was the missing piece of the puzzle. I think I understand how to make things work now. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 14, 2009 at 6:32 PM, Ned Deily n...@acm.org wrote: The OSX installer script is in Mac/BuildScript/build-installer.py. For 2-way builds, it essentially does: export MACOSX_DEPLOYMENT_TARGET=10.3 configure -C --enable-framework --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs='32-bit' --with-computed-gotos OPT='-g -O3' Great---thank you! And thank you for all the testing. I'll try to sort all this out later this evening (GMT+1); I think I understand how to fix everything now. 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
I rather like supporting short float representation. Given that CPython is adopting it, I'm sure Jython will adopt this approach too as part of a future Jython 3.x release. - Jim On Tue, Apr 7, 2009 at 9:41 AM, Michael Foord fuzzy...@voidspace.org.ukwrote: Mark Dickinson wrote: [snip...] Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. Big +1 (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. Short float repr should be an implementation detail, so long as eval(repr(x)) == x still holds. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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/jbaker%40zyasoft.com -- Jim Baker jba...@zyasoft.com ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On 14 Apr, 2009, at 18:09, Mark Dickinson wrote: Okay, I think I might have fixed up the float endianness detection for universal builds on OS X. Ned, any chance you could give this another try with an updated version of the py3k-short-float-repr branch? One thing I don't understand: Is it true that to produce a working universal/fat build of Python, one has to first regenerate configure and pyconfig.h.in using autoconf version = 2.62? If not, then I don't understand how the AC_C_BIGENDIAN autoconf macro can be giving the right results. It cannot, the actual bigendian detection for universal build is done in pymacconfig.h. I have given up on getting pyconfig.h right for universal builds, especially when dealing with 4-way universal builds. Ronald 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/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark has uploaded our newest work to Rietveld, again at
http://codereview.appspot.com/33084/show. Since the last version, Mark
has added 387 support (and other fixes) and I've added localized
formatting ('n') back in as well as ',' formatting for float and int. I
think this addresses all open issues. If you have time, please review
the code on Rietveld.
We believe we're ready to merge this back into the py3k branch. Pending
any comments here or on Rietveld, we'll do the merge in the next day or so.
Before then, if anyone could build and test the py3k-short-float-repr
branch on any of the following machines, that would be great:
Windows (preferably 64-bit)
Itanium
Old Intel/Linux (e.g., the snakebite nitrogen box)
Something bigendian, like a G4 Mac
We're pretty well tested on x86 Mac and Linux, and I've run it once on
my Windows 32-bit machine.
I have a Snakebite account, and I'll try running on nitrogen once I
figure out how to log in again.
I just had Itanium and PPC buildbots test our branch, and they both
succeeded (or at least failed with errors not related to our changes).
Eric.
___
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
Re: [Python-Dev] Shorter float repr in Python 3.1?
2009/4/13 Eric Smith e...@trueblade.com:
Mark has uploaded our newest work to Rietveld, again at
http://codereview.appspot.com/33084/show. Since the last version, Mark has
added 387 support (and other fixes) and I've added localized formatting
('n') back in as well as ',' formatting for float and int. I think this
addresses all open issues. If you have time, please review the code on
Rietveld.
We believe we're ready to merge this back into the py3k branch. Pending any
comments here or on Rietveld, we'll do the merge in the next day or so.
Cool. Will you use svnmerge.py to integrate the branch? After having
some odd behavior merging the io-c branch, suggest you just apply a
patch to the py3k branch,
--
Regards,
Benjamin
___
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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Benjamin Peterson wrote: Cool. Will you use svnmerge.py to integrate the branch? After having some odd behavior merging the io-c branch, suggest you just apply a patch to the py3k branch, We're just going to apply 2 patches, without using svnmerge. First we'll add new files and the configure changes. Once we're sure that builds everywhere, then the second step will actually hook in the new functions and will have the formatting changes. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
In article 49e3d34e.8040...@trueblade.com, 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 Deily, n...@acm.org ___ 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
[Python-Dev] Shorter float repr in Python 3.1?
Executive summary (details and discussion points below)
=
Some time ago, Noam Raphael pointed out that for a float x,
repr(x) can often be much shorter than it currently is, without
sacrificing the property that eval(repr(x)) == x, and proposed
changing Python accordingly. See
http://bugs.python.org/issue1580
For example, instead of the current behaviour:
Python 3.1a2+ (py3k:71353:71354, Apr 7 2009, 12:55:16)
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type help, copyright, credits or license for more information.
0.01
0.01
0.02
0.02
0.03
0.02
0.04
0.040001
0.04 == eval(repr(0.04))
True
we'd have this:
Python 3.1a2+ (py3k-short-float-repr:71350:71352M, Apr 7 2009, )
[GCC 4.0.1 (Apple Inc. build 5490)] on darwin
Type help, copyright, credits or license for more information.
0.01
0.01
0.02
0.02
0.03
0.03
0.04
0.04
0.04 == eval(repr(0.04))
True
Initial attempts to implement this encountered various
difficulties, and at some point Tim Peters pointed out
(I'm paraphrasing horribly here) that one can't have all
three of {fast, easy, correct}.
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.
Any thoughts/objections/counter-proposals/...?
More details
Our solution is based on an adaptation of David Gay's
'perfect rounding' code for inclusion in Python. To make
eval(repr(x)) roundtripping work, one needs to have
correctly rounded float - decimal *and* decimal - float
conversions: Gay's code provides correctly rounded
dtoa and strtod functions for these two conversions.
His code is well-known and well-tested: it's used as the
basis of the glibc strtod, and is also in OS X. It's
available from
http://www.netlib.org/fp/dtoa.c
So our branch contains a new file Python/dtoa.c,
which is a cut down version of Gay's original file. (We've
removed stuff for VAX and IBM floating-point formats,
hex NaNs, hex floating-point formats, locale-aware
interpretation of the decimal separator, KR headers,
code for correct setting of the inexact flag, and various
other bits and pieces that Python doesn't care about.)
Most of the rest of the work is in the existing file
Python/pystrtod.c. Every float - string or string - float
conversion goes through a function in this file at
some point.
Gay's code also provides the opportunity to clean
up the current float formatting code, and Eric has
reworked a lot of the float formatting in the py3k-short-float-repr
branch. This reworking should make finishing off the
implementation of things like thousands separators much
more straightforward.
One example of this: the previous string - float conversion
used the system strtod, which is locale-aware, so the code
had to first replace the '.' by the current locale's decimal
separator, *then* call strtod. There was a similar dance in
the reverse direction when doing float - string conversion.
Both these are now unnecessary.
The current code is pretty close to ready for merging
to py3k. I've uploaded a patchset to Rietveld:
http://codereview.appspot.com/33084/show
Apart from the short float repr, and a couple of bugfixes,
all behaviour should be unchanged from before. There
are a few exceptions:
- format(1e200, '') doesn't behave quite as it did
before. See item (3) below for details
- repr switches to using exponential notation at
1e16 instead of the previous 1e17. This avoids
a subtle issue where the 'short float repr' result
is padded with bogus zeros.
- a similar change applies to str, which switches
to exponential notation at 1e11, not 1e12. This
fixes the following minor annoyance, which goes
back at least as far as Python 2.5 (and probably
much further):
x = 1e11 + 0.5
x
1000.5
print(x)
1000.0
That .0 seems wrong to me: if we're going to
go to the trouble of printing extra digits (str
usually only gives 12 significant digits; here
there are 13), they should be the *right* extra digits.
Discussion points
=
(1) Any objections to including this into py3k? If there's
controversy, then I guess we'll need a PEP.
(2) Should other Python implementations (Jython,
IronPython, etc.) be expected to use short float repr, or should
it just be considered an implementation detail of CPython?
I propose the latter, except that all implementations should
be required to satisfy eval(repr(x)) == x for finite floats x.
(3) There's a PEP 3101 line we don't know what to do with.
In py3k, we currently have:
format(1e200, '')
'1.0e+200'
but in our py3k-short-float-repr branch:
format(1e200, '')
'1e+200'
Which is correct? The py3k behaviour
comes from the 'Standard Format Specifiers' section of
PEP 3101, where it says:
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson wrote: [snip...] Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. Big +1 (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. Short float repr should be an implementation detail, so long as eval(repr(x)) == x still holds. Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
It would have helped if I'd copied the list... Sorry, Paul. 2009/4/7 Paul Moore p.f.mo...@gmail.com: 2009/4/7 Michael Foord fuzzy...@voidspace.org.uk: Mark Dickinson wrote: [snip...] Discussion points = (1) Any objections to including this into py3k? If there's controversy, then I guess we'll need a PEP. Big +1 (2) Should other Python implementations (Jython, IronPython, etc.) be expected to use short float repr, or should it just be considered an implementation detail of CPython? I propose the latter, except that all implementations should be required to satisfy eval(repr(x)) == x for finite floats x. Short float repr should be an implementation detail, so long as eval(repr(x)) == x still holds. What he said :-) Paul. ___ 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
Re: [Python-Dev] Shorter float repr in Python 3.1?
Mark Dickinson wrote:
One PyCon 2009 sprint later, Eric Smith and I have
produced the py3k-short-float-repr branch, which implements
short repr of floats and also does some major cleaning
up of the current float formatting functions.
We've gone for the {fast, correct} pairing.
We'd like to get this into Python 3.1.
Any thoughts/objections/counter-proposals/...?
As part of the decision process, we've tried this on several buildbots,
and it has been successful on at least:
AMD64 Gentoo:
http://www.python.org/dev/buildbot/3.x/amd64%20gentoo%203.x/builds/592
PPC Debian unstable:
http://www.python.org/dev/buildbot/3.x/ppc%20Debian%20unstable%203.x/builds/584
Sparc Solaris 10:
http://www.python.org/dev/buildbot/3.x/sparc%20solaris10%20gcc%203.x/builds/493
The Sparc test failed, but that wasn't our fault! Our tests succeeded.
These builds are in addition to x86 Linux and x86 Mac, which we've
developed on.
Eric.
___
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
Re: [Python-Dev] Shorter float repr in Python 3.1?
On Tue, Apr 07, 2009, Mark Dickinson wrote: Executive summary (details and discussion points below) = Some time ago, Noam Raphael pointed out that for a float x, repr(x) can often be much shorter than it currently is, without sacrificing the property that eval(repr(x)) == x, and proposed changing Python accordingly. See http://bugs.python.org/issue1580 Sounds good to me! -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ ...string iteration isn't about treating strings as sequences of strings, it's about treating strings as sequences of characters. The fact that characters are also strings is the reason we have problems, but characters are strings for other good reasons. --Aahz ___ 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
