[ruby-core:39566] [Ruby 1.9 - Bug #4576] Range#step miss the last value, if end-exclusive and has float number

Issue #4576 has been updated by Marc-Andre Lafortune.

Category set to core
Target version set to 1.9.4

Hi,

In this long thread, I could not find a single argument against the (3-line) patch.

Does the patch cause a problem? No

Does the patch fix a platform inconsistency? Yes

The patch has been committed as r33282

The question that remains: there might be other issues like this one. Would compiling with "cflags=-ffloat-store" on affected platforms cause a significant performance loss?



Below are some comments on what has been said before:

On Sun, Apr 17, 2011 at 8:59 PM,  <[e-mail]> wrote:
> Fixed in r31286.

The commit message of r31304 said "avoid float error". The correct phrasing is "ignore float error". Changing a failing test for another one that doesn't show the problem is not fixing anything. It is playing the ostrich (and yes, I know ostriches don't actually bury their head in the sand).

On Tue, Sep 13, 2011 at 7:50 AM, Shyouhei Urabe <[e-mail]> wrote:
> It is a clear sign that you are "dancing with floats".
>
> As Tomoyoki Chikanaga says in note #note-2 of this issue I believe this is a "learn floating point number" kind of thig.

Yes, floats can be complicated. No I wouldn't recommend to anyone to play with tight limits with floats. But here, it is simply not acceptable that `(foo...bar).step(baz).to_a.last == bar`. On any platform. This is not a question of learning floating point number.


On Tue, Sep 13, 2011 at 9:13 AM, Shyouhei Urabe <[e-mail]> wrote:
> No.  Sorry.  Ruby is not designed like that.  Ruby's design is that it embraces the world we live, no matter it is ugly.  Ruby do not hide its ugliness from your eyes.

What makes you think this? This is simply not true. Math in Ruby aims to be as platform independent as is reasonable. For example see Matz in [ruby-core:28212].


On Tue, Sep 13, 2011 at 11:01 AM, Kenta Murata <[e-mail]> wrote:
> you can use BigDecimal as following:

I understand this is meant to be helpful to the original poster, but the reasoning "if there is a problem with Float, let's use BigDecimal" is flawed. It does not improve Ruby, it does not address the problem. Float methods should be fixed (within the inherent limits of Floats). Otherwise where draw the limit? Would it be ok if `Float("3.0e-31").to_s == "3.0000000000000003e-31"`?


On Tue, Sep 13, 2011 at 11:19 AM, Yusuke ENDOH <[e-mail]> wrote:
> However, Test E still looks like "apparently wrong" on my i386:
>
>  $ ./miniruby -e 'p (1.0...128.4).step(18.2).to_a'
>  [1.0, 19.2, 37.4, 55.599999999999994, 73.8, 92.0,
> 110.19999999999999, 128.39999999999998]

Here we have to accept this result, due to rounding error with Floats. 7 * 18.2 + 1.0 == 128.39999999999998 < 128.4
This result holds accross all IEEE 194 platforms, etc...

----------------------------------------
Bug #4576: Range#step miss the last value, if end-exclusive and has float number
http://redmine.ruby-lang.org/issues/4576

Author: Joey Zhou
Status: Closed
Priority: Normal
Assignee: 
Category: core
Target version: 1.9.4
ruby -v: -


=begin
Hi, I find that:

* if: range.exclude_end? == true
* and: any one in [begin_obj, end_obj, step] is a true Float(f.to_i != f)
* and: unless begin_obj + step*int == end_obj
* then: the result will miss the last value.

for example:

 p (1...6.3).step.to_a # => [1.0, 2.0, 3.0, 4.0, 5.0], no 6.0
 p (1.1...6).step.to_a # => [1.1, 2.1, 3.1, 4.1], no 5.1
 p (1...6).step(1.1).to_a # => [1.0, 2.1, 3.2, 4.300000000000001], no 5.4

 p (1.0...6.6).step(1.9).to_a # => [1.0, 2.9], no 4.8
 p (1.0...6.7).step(1.9).to_a # => [1.0, 2.9, 4.8]
 p (1.0...6.8).step(1.9).to_a # => [1.0, 2.9, 4.8], no 6.7

Maybe the #step is ok on integers, but there's something wrong if the range is end-exclusive and contain float numbers.
=end



-- 
http://redmine.ruby-lang.org