Bug #2144: Split functionality of Float#inspect and Float#to_s

• Status: Rejected
• Assignee: -
• Target version: 1.9.2
• ruby -v: ruby 1.9.2dev (2009-09-26 trunk 25103) [i386-mingw32]

[rogerdpack (Roger Pack)]

=begin
Currently the Float#to_s and Float#inspect return an "accurate" representation of the internal float, to help alert users of floating point inconsistencies.

This is better than the old way, however some have pointed out that the old functionality has been lost [the old "pretty float" style].

In order to have 1.9.2 add functionality and not also lose the old functionality, this is a proposal to make

String#to_s the pretty way
and
String#inspect
Show the accurate way.
Then in irb users are notified of inaccuracies, and it's also more backward compatible.

I'd be ok with the two going the other way, too--just as long as there's both available somewhere.

Thanks!
-r
=end

[marcandre (Marc-Andre Lafortune)]

• Category set to core
• Status changed from Open to Rejected

=begin
Hi

1. I believe the current trunk always return what I think you the "pretty float" style.

0.1.to_s # ==> "0.1"

Note that 0.1 is not stored (on most platforms) as exactly 0.1 because it can't be expressed as fixnum * 2 ^ fixnum. Currently, this can be seen with 0.1.to_r which does not return 1/10 (see issue #1408)

2. I believe you are mistaken in thinking there is one and only one "accurate" representation of a given float number. It is important to remember that a Float is always an approximation.

1.0 has to be understood as 1.0 +/- EPSILON, where the EPSILON is platform dependent. 1.0 is not more equal to 1 than to 1 + EPSILON/2. Indeed, there is no way to distinguish either when they are stored as floats.

To believe that Float#to_s loses data is wrong. If r.to_s returns "1.2", it implies that 1.2 is one of the values in the range of possible values for that floating number. It could have been 1.2000...0006. Or something else. There is no way to know, so #to_s chooses, wisely, to return the simplest value in the range.

Note also that the way a double is stored is platform dependent, at least in theory (I don't know of any that doesn't use the same one currently).

Finally, I'm closing this as this is not a bug report. If you really would like to have a string representation that is the closest approximation to the platform dependent representation of a given float, please open a feature request for it explaining why you would need this and how you would use this.
Thanks

=end