[#22684] [Bug #1247] YAML::load converts some dates into strings — Matthew Wilson <redmine@...>

Bug #1247: YAML::load converts some dates into strings

10 messages 2009/03/05

[#22725] [Bug #1253] Fix MSVC Build Issues — Charlie Savage <redmine@...>

Bug #1253: Fix MSVC Build Issues

13 messages 2009/03/07

[#22727] Moving ruby 1.9.1 forward on windows — Charlie Savage <cfis@...>

Hi everyone,

14 messages 2009/03/08

[#22731] [Bug #1255] += for large strings egrigiously slow — James Lee <redmine@...>

Bug #1255: += for large strings egrigiously slow

11 messages 2009/03/08

[#22736] Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...>

Moin, moin!

13 messages 2009/03/08
[#22739] Re: Ruby 1.9.1 and tail recursion optimization — =?ISO-8859-15?Q?Wolfgang_N=E1dasi-Donner?= <ed.odanow@...> 2009/03/08

Wolfgang N疆asi-Donner schrieb:

[#22748] [Feature #1256] Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented — Wolfgang Nádasi-Donner <redmine@...>

Feature #1256: Add constant TAILRECURSION to let a program recognize if tail recursion optimization is implemented

7 messages 2009/03/08

[#22803] Relegate 1.8.6 to Engine Yard, part II — Urabe Shyouhei <shyouhei@...>

Hello and sorry for my being slow for this issue. It's OK now for me to pass

21 messages 2009/03/10

[#22812] [Bug #1261] cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR — Daniel Golle <redmine@...>

Bug #1261: cross-compiling Ruby extensions using mkmf doesn't fully respect DESTDIR

8 messages 2009/03/10

[#22892] Ruby Time — valodzka <valodzka@...>

Got tired of current ruby Time limitation, I have written this -

24 messages 2009/03/14
[#22949] Re: Ruby Time — Tanaka Akira <akr@...> 2009/03/19

In article <9e19ed87-9d12-4f98-af3c-bd49a71b0bd4@p11g2000yqe.googlegroups.com>,

[#22974] Re: Ruby Time — valodzka <valodzka@...> 2009/03/20

[#22977] Re: Ruby Time — Urabe Shyouhei <shyouhei@...> 2009/03/20

valodzka wrote:

[#22981] Re: Ruby Time — valodzka <valodzka@...> 2009/03/21

> I bet you'll get tired of updating that database. There's a major difference

[#22893] [Feature #1291] O_CLOEXEC flag missing for Kernel::open — David Martin <redmine@...>

Feature #1291: O_CLOEXEC flag missing for Kernel::open

10 messages 2009/03/15

[#22939] [Bug #1303] A name considered a local variable on RHS of an assignment that defines it — Tomas Matousek <redmine@...>

Bug #1303: A name considered a local variable on RHS of an assignment that defines it

8 messages 2009/03/19

[#23063] [Bug #1332] Reading file on Windows is 500x slower then with previous Ruby version — Damjan Rems <redmine@...>

Bug #1332: Reading file on Windows is 500x slower then with previous Ruby version

11 messages 2009/03/30

[#23075] [Bug #1336] Change in string representation of Floats — Brian Ford <redmine@...>

Bug #1336: Change in string representation of Floats

37 messages 2009/03/31
[#23179] [Bug #1336] Change in string representation of Floats — Roger Pack <redmine@...> 2009/04/11

Issue #1336 has been updated by Roger Pack.

[#23181] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/11

[#23186] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/12

Hi,

[#23187] Re: [Bug #1336] Change in string representation of Floats — Brent Roman <brent@...> 2009/04/13

[#23188] Re: [Bug #1336] Change in string representation of Floats — Yukihiro Matsumoto <matz@...> 2009/04/13

Hi,

[ruby-core:22721] Re: suggestions for float

From: Charles Oliver Nutter <charles.nutter@...>
Date: 2009-03-07 17:43:23 UTC
List: ruby-core #22721
Brent Roman wrote:
> Floats are imprecise by design.  They are intended to represent measured
> quantities, not countable objects.  Any real valued measurement is likely to
> have more error in its underlying physics than the 8-byte binary floating
> point format Ruby uses to approximate that value.

I've been forced to argue this point many times because Ruby gives the 
illusion that Floats "aren't necessarily" precise due to the "prettying 
up" of to_s results. So when JRuby presented the real IEEE floating 
point result, we had to "fix" it...

> A variant of the float to string conversion that tries to preserve all the
> binary information would certainly be useful, but not as the default to_s
> method.  That is, unless you think that:
> 
> irb>  2.1 - 3.0
> -0.8999999999999999
> 
> would not be "surprising"!  (well, at least annoying)

We had to "fix" this sort of case in JRuby because our to_s was 
returning repeating the repeating decimal versions of many Floats. I 
found it annoying that many tests in Rails and RubySpec and elsewhere 
expected floating point math to produce a specific accurate or integral 
result in most cases.

While I appreciate that returning -0.9 for the above "looks" nicer, it 
also helps reinforce the myth that floating-point results are 100% 
accurate. The bugs JRuby had (and in some cases still has) representing 
floating point math results the same way as MRI have often led to broken 
code as a result...such as a certain piece of code in Rails that 
multiplied a float and an integer and compared it with another float 
with no margin for error. Pretending Floats are accurate leads to bugs.

- Charlie

In This Thread