[#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:29185] Re: [Feature #2152] Split functionality of Float#inspect and Float#to_s

From: Roger Pack <rogerdpack2@...>
Date: 2010-03-31 22:46:13 UTC
List: ruby-core #29185
>> 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.

True--for me, though, having to_s "pretty" and inspect show you what
is going on seems to satisfy both cases...

> 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.

Agreed.  Currently, though, we dislike the old behavior and many
dislike the new behavior, too.




> 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 =
double.

It looks ok to me:

1.8.6:

>> 1.4 - 0.1 - 1.2
=3D> 0.09999999999999986700

C:\dev>pik 192

>> 1.4 - 0.1 - 1.2
=3D> 0.09999999999999987

Thoughts?
-rp

In This Thread