Movatterモバイル変換
[0]ホーム
[Python-Dev] Round Bug in Python 1.6?
Ka-Ping Yeeping@lfw.org
Fri, 7 Apr 2000 13:47:45 -0500 (CDT)
Tim Peters wrote:> The best possible IEEE-754 double approximation to 3.1416 is (exactly)>> 3.141599999999999948130380289512686431407928466796875Let's call this number 'A' for the sake of discussion.> so the output you got is correctly rounded to 17 significant digits. IOW,> it's a feature.Clearly there is something very wrong here: Python 1.5.2+ (#2, Mar 28 2000, 18:27:50) Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam >>> 3.1416 3.1415999999999999 >>>Now you say that 17 significant digits are required to ensurethat eval(repr(x)) == x, but we surely know that 17 digits are*not* required when x is A because i *just typed in* 3.1416 andthe best choice of double value was A.I haven't gone and figured it out, but i'll take your word forit that 17 digits may be required in *certain* cases to ensurethat eval(repr(x)) == x. They're just not required in all cases.It's very jarring to type something in, and have the interpretergive you back something that looks very different. It breaks afundamental rule of consistency, and that damages the user'strust in the system or their understanding of the system. (Whatdo you do then, start explaining the IEEE double representationto your CP4E beginner?)What should really happen is that floats intelligently print inthe shortest and simplest manner possible, i.e. the fewestnumber of digits such that the decimal representation willconvert back to the actual value. Now you may say this is apain to implement, but i'm talking about sanity for the user here.I haven't investigated how to do this best yet. I'll go offnow and see if i can come up with an algorithm that's notquite so stupid as def smartrepr(x): p = 17 while eval('%%.%df' % (p - 1) % x) == x: p = p - 1 return '%%.%df' % p % x-- ?!ng
[8]ページ先頭