> Issue #2152 has been updated by Marc-Andre Lafortune.
>
> There are two different issues here.
>
> 1) First, there is currently a bug in trunk:
>
> 72.9.to_s # =3D=3D> "72.90000000000001"
>
> #to_s (and #inspect) should choose the simplest string representation tha=
t is included in the approximate range a float represents.

That's what we ask for #to_s
We'd like to keep #inspect to find easily why a calculation is wrong
(and even if you know how Float are, this security is really not too
much, so much "bugs" can happen)

>
> In other words, if string_rep_1.to_f =3D=3D string_rep_2.to_f, then the s=
implest of string_rep_1 and string_rep_2 is to be preferred.
>

Agreed for to_s, inspect is here irrelevant.

> 2) Calculations between floats introduce errors due to these approximatio=
ns. For example:
>
> (1-0.9) =3D=3D 0.1 # =3D=3D> false
>
> This feature request asks that (1-0.9).to_s =A0# =3D> "0.1"

No, but it's one consequence. 1.8 behave like this. Nobody would ever
want to compare the String representations to compare the value...

> I object to this, because 1-0.9 is not =3D=3D to 0.1 and thus should not =
have the same string representation.

I think it should. It's in fact inconsistent now to read from a String
"72.9".to_f.to_s
Again, inspect has no matter with it. It's intended for showing full
representation as I think.

> I would recommend that instead we consider adding (probably in 1.9.3) an =
optional argument to Float#to_s that would limit the number of decimal show=
ing, for instance.

That's a good idea, better than old way "%.20f" % 0.1

I think we really need the old #to_s for 1.9.2, it's definitely
inconsistent the current representation.
Do you agree?