[#28687] [Bug #2973] rb_bug - Segmentation fault - error.c:213 — rudolf gavlas <redmine@...>

Bug #2973: rb_bug - Segmentation fault - error.c:213

10 messages 2010/03/16

[#28735] [Bug #2982] Ruby tries to link with both openssl and readline — Lucas Nussbaum <redmine@...>

Bug #2982: Ruby tries to link with both openssl and readline

16 messages 2010/03/18

[#28736] [Bug #2983] Ruby (GPLv2 only) tries to link to with readline (now GPLv3) — Lucas Nussbaum <redmine@...>

Bug #2983: Ruby (GPLv2 only) tries to link to with readline (now GPLv3)

10 messages 2010/03/18

[#28907] [Bug #3000] Open SSL Segfaults — Christian Höltje <redmine@...>

Bug #3000: Open SSL Segfaults

19 messages 2010/03/23

[#28924] [Bug #3005] Ruby core dump - [BUG] rb_sys_fail() - errno == 0 — Sebastian YEPES <redmine@...>

Bug #3005: Ruby core dump - [BUG] rb_sys_fail() - errno == 0

10 messages 2010/03/24

[#28954] [Feature #3010] slow require gems in ruby 1.9.1 — Miao Jiang <redmine@...>

Feature #3010: slow require gems in ruby 1.9.1

15 messages 2010/03/24

[#29179] [Bug #3071] Convert rubygems and rdoc to use psych — Aaron Patterson <redmine@...>

Bug #3071: Convert rubygems and rdoc to use psych

10 messages 2010/03/31

[ruby-core:29181] Re: [Feature #2152] Split functionality of Float#inspect and Float#to_s

From: Benoit Daloze <eregontp@...>
Date: 2010-03-31 21:01:14 UTC
List: ruby-core #29181
Hi,
On 31 March 2010 21:39, Yusuke ENDOH <mame@tsg.ne.jp> wrote:
> Hi,
> No. =A0You are asking the different behavior from Marc-Andre.
>
> Marc-Andre is insisting it choose the simplest representation
> *without inaccuracy*. =A0But the old behavior you want chooses
> 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:
>
> =A0p 1.4 - 0.1 - 1.2 =A0#=3D> 0.0999999999999999
>
> 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. =A0But I knew that the
> implementation of the old behavior was very uncool and dirty.
> It is almost like:
>
> =A0("%.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 =3D 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 =3D 1.4 - 0.1 - 1.2
=3D> 0.09999999999999987
> "%.15f" % n
=3D> "0.100000000000000"
> "%.16f" % n
=3D> "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 do=
uble.

In This Thread