[ruby-core:35766] [Ruby 1.9 - Bug #4577] (int...float).max should not raise an error

Issue #4577 has been updated by Joey Zhou.


Ranges with numbers as begin_obj and end_obj can be summarized to four(..and...):

 int..int # no problem
 float..float # no problem, float has no #succ, cannot iterate
 float..int # act as float..float, no problem, no #succ, no iteration
 int..float # I think more attention should be paid to this...

I suggest the feature here:

when int..float is used in #cover? #include? #===, there's no problem, just: begin_obj <=> obj and obj <=> end_obj

but when int..float(and int...float) is used in any method requiring iteration, the fractional part of float, may be dropped as scrap, if *needed*.

 (1..5.3).to_a #=> [1,2,3,4,5]
 (1..5.0).to_a #=> [1,2,3,4,5]
 (1...5.3).to_a #=> [1,2,3,4,5]
 (1...5.0).to_a #=> [1,2,3,4]
 (1..5.3).last(1) #=> [5]
 (1...5.3).last(1) #=> [5]

the methods above are all OK, you can say there's a implicit rule: "0.3 is scrap, we dropped it"

but #last and #max:

 (1..5.3).last #=> 5.3
 (1...5.3).last #=> 5.3
 (1..5.3).max #=> 5.3, well, same as #end
hmm, #end, #last(no arg), #max(no block) all act the same, why should we need three methods to tell the end_obj?
 (1...5.3).max # ERROR!

 (1..5.3).max {|a,b| a <=> b} # 5, fraction-scrap
 (1...5.3).max {|a,b| a <=> b} # 5 too

If the single #max follow "fraction-scrap" rule, I think it's better
 (1..5.3).max #=> 5
 (1...5.3).max #=> 5
 (1...5.0).max #=> 4
----------------------------------------
Bug #4577: (int...float).max should not raise an error
http://redmine.ruby-lang.org/issues/4577

Author: Joey Zhou
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 
ruby -v: -


(int...float).max (without a block) will raise an error:

(({p (1...9.3).max # cannot exclude non Integer end value (TypeError)}))

I don't think it should do so.

int...float is a valid range object. When I construct such range, there's no error message.

The range can call all the Range instance methods. Only when calling single #max, the errmsg seems to tell that the range itself is not valid.

#max with a block will not raise the error:

(({p (1...9.3).max {|a,b| a <=> b} #=> 9}))

I think (1...9.3).max should also return 9( (end_obj-1).ceil ). If you admit the legality of #max(&block), you should also admit #max().


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