Hi,
On 31 March 2010 21:39, Yusuke ENDOH <mame / tsg.ne.jp> wrote:
> Hi,
> No.  ¨Âïõ áòáóëéîç ôèäéææåòåîâåèáöéïò æòïí Íáòã­Áîäòå>
> Marc-Andre is insisting it choose the simplest representation
> *without inaccuracy*.  ¨Âõô ôèïìâåèáöéïò ùï÷áîô ãèïïóå> a simple one *that may be even inaccurate*.

You're right, I considered simplest as *not so accurate but concise*.

> Even in 1.8, the following returns the result including error:
>
>  ¨Â ±®°®±®½¾ °®°¹¹¹¹¹¹¹¹¹¹¹¹¹¹¹
>
> It may cause a bug that is hard to test and reproduce.

I never noticed that in 1.8, so I suppose is quite rare.
Maybe we should accept an epsilon, appropriate for the double type,
that depends of the range between 2 double
and then "round" the Float when we want to print.
Or maybe decide of a fixed number of decimals is easier ?

I think nobody likes ...9999999999 when the exact result would be
....1(0000), even if the internal value could never be that number.

Let's make Float beautiful with default printing ;)

> Honestly, I used to like the old behavior.  ¨Âõô ëîå÷ ôèáô ôè> implementation of the old behavior was very uncool and dirty.
> It is almost like:
>
> "%.15f" % float).sub(/0+$/, "")
>
> Now I dislike the old behavior.

For what I have read in the C code, it's in fact very different
between versions.
I think a good idea would to allow that optional parameter that would
basically act as:
def to_s(n = DEFAULT_PRECISION)
  "%.#{n}f" % float # Please write this in C as beautiful as you can :)
end
and the default value be according to have a similar result to 1.8.

Well, and if both implementation have pro/cons, then isn't the first
proposition a solution ?
Let people happy with beautiful output when result is (almost) exact,
and let them *inspect* the object to see what's the real value (and
have a better implementation there)

We are most of us agreeing to a cleaner syntax, while we don't want to
cheat and remove too much accuracy

So, double have a range of (2**-52) ~ 2e-16. We then should round at
15~16 digits:

> n = 1.4 - 0.1 - 1.2
=> 0.09999999999999987
> "%.15f" % n
=> "0.100000000000000"
> "%.16f" % n
=> "0.0999999999999999"

15 looks fine to me, because we all know Float aren't accurate with
some operations.

Current implementation go until the 17th digit, which is non-sense for a double.