Ok, I wrote a patch! http://bugs.python.org/issue1580
Now you have: >>> 1.1 1.1 It works! And it passes the test suite! I added a test which takes a list of about a 1000 floating point numbers which were designed to check binary to decimal conversion. It turns out that Tcl implemented this algorithm for tcl8.5 (which is currently in beta stage). See http://www.tcl.tk/cgi-bin/tct/tip/132.html for the TIP (that's how they call a PEP...) I took the formatting function (which is quite simple) from them. For the main algorithm, which converts a double to the shortest list of digits needed to recreate it, I used the code by Robert G. Burger (the author of the article) since it is stand-alone. The original code can be found here: http://www.cs.indiana.edu/~burger/fp/index.html The patch is against current py3k svn. Have a good day, Noam 2007/12/9, Noam Raphael <[EMAIL PROTECTED]>: > Hello, > > I would like to re-raise the issue of float repr() -- making repr(1.1) > == '1.1' instead of '1.1000000000000001'. > > My use case is data manipulation in the interactive shell - an > extremely powerful tool which, it seems, not so many people use. Many > times I have float data. I think that you'll agree with me that, for > example: > > >>> height['Alice'] > 1.67 > > Is much easier to understand than > > >>> height['Alice'] > 1.6699999999999999 > > Not to mention > > >>> height > {'David': 1.81, 'Alice': 1.67, 'Bob': 1.76, 'Barbara': 1.65} > > Versus: > > >>> height > {'Bob': 1.76, 'Barbara': 1.6499999999999999, 'Alice': > 1.6699999999999999, 'David': 1.8100000000000001} > > > I think that the reason for the long representation is that it uses a > simple algorithm that makes "eval(repr(f)) == f" always true. However, > why not use another, a bit more complex, algorithm, which will still > preserve "eval(repr(f)) == f", but which will shorten the result when > it can? > > You see, it's not even that the current algorithm is exact - for > example, the actual, stored, representation of 1.67 is, on my > computer, 1.1010101110000101000111101011100001010001111010111. The > exact decimal representation of that number is > 1.6699999999999999289457264239899814128875732421875. I agree that > "1.6699999999999999" is better, but isn't "1.67" the best? > > Have a good day, > Noam > _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
