From: Brent Roman Date: 2009-04-06T03:23:14+09:00 Subject: [ruby-core:23123] Re: [Bug #1336] Change in string representation of Floats I have to agree with Brian on this. A quick, informal survey of various other languages shows that, by default, most will faithfully convert floating point 2.4 from a string to float and back again. 'C', 'C++', Lua, Haskell, Matlab, BASIC, Pascal, etc. all output "2.4" when their best floating point approximation of 2.4 is converted to a string with default options. Python, however, does output 2.3999... While someone can probably find another commonly used language that behaves as Python does in this regard, I'm sure such languages are firmly in the minority. A good compromise solution, in Ruby's case, would be to redefine Float#inspect such that it preserves the value's full precision without rounding (for round-tripping, ultimate "truth", or whatever), while leaving Float#to_s as it was. This is consistent with other uses of the inspect method. Consider, for example, that String and Symbol#to_s will return unquoted, ambiguous output strings, while the corresponding #inspect methods return fully quoted, unambiguous results. It might also be a good idea to include a paragraph or two about the behavior of limited precision floating point numbers in Ruby Doc for the Float class. Include {puts 2.4} verses {p 2.4} as an example. After all, the crux of this issue is education about the behavior of Floats that every programmer using them really needs to understand, regardless of how they are output. Having said all this, I'm not going to get too worked up about it. I will just sigh and add: class Float def to_s "%g" % self end end to the home grown Ruby version compatibility library that I already require in most of my apps. - brent brixen wrote: > > On Fri, Apr 3, 2009 at 11:49 PM, Roger Pack wrote: >> Issue #1336 has been updated by Roger Pack. >> >> >>>> * numeric.c (flo_to_s): keeps enough precision for round trip. >> >> One possibility would be to allow Float#to_s to still be (depending on >> how you look at it) "friendly" or "imprecise." >> >> And keep the precise version for Float#inspect. >> >> The benefit of having them both verbose is that (tongue in cheek) it >> makes floats hideously ugly which might encourage people to avoid them :) >> >> But having both available separately via #inspect and #to_s would be nice >> and I'd imagine a patch to that effect would be well received. >> >> A discussion on it can be read at http://www.ruby-forum.com/topic/179361 > > It's not an issue of float precision. It is an issue of representation > and there are many possibly representations of a float. The previous > representation was user-friendly. The change is not. > > The only justification for the change that I see is this idea that > there is value to being able to round trip a float from #to_s through > eval. However, I think that is a poor reason to change because: > > 1. I can count the number Ruby classes that can be round-tripped this > way on one hand. > 2. There is a perfectly good mechanism for round-tripping any Ruby object. > 3. If you don't want to marshal, you can use #sprintf when *you* want > to round-trip a float via a string and eval. > 4. The vast majority of times a float is represented as a string it is > *not* to round-trip. > > So, this decision takes a marginal case for which a perfectly good > mechanism already exists and promotes it to the common case. But > that's not all. The consequence for the common case is that 2.4 is > unnecessarily and uselessly echoed back to me as 2.3999999999999999. > > It is very poor interface design to promote a marginal case above a > common case. There is nothing that this change in representation makes > better in the common case. It makes the common case hideous. > > Floats are what they are. Use them as you will. Ruby used to have > nice, friendly representations of floats for humans. Nothing gained, > much lost. The decision should be reversed. > > Brian > >> >> Cheers. >> -=r >> ---------------------------------------- >> http://redmine.ruby-lang.org/issues/show/1336 >> >> ---------------------------------------- >> http://redmine.ruby-lang.org >> >> > > > -- View this message in context: http://www.nabble.com/-ruby-core%3A23075---Bug--1336--Change-in-string-representation-of-Floats-tp22798535p22896937.html Sent from the ruby-core mailing list archive at Nabble.com.