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

Issue #4577 has been updated by Joey Zhou.


Well, what I mean is ((*#max without block*)) and ((*#max {block}*)) should act the same way, maybe.

 (1...6.3).max {|a,b| a <=> b} # 6

Why this one can iterate from 1 to 6, but not single #max ?

It seems there are two #max, one support #each, and another not.

I think this results in confusion.

Here:

 p (1..6.3).last     # 6.3, same as (1..6.3).end
 p (1..6.3).last(1)  # [6]
 p (1...6.3).last(1) # [6], well... not [6.3]

two dots, or three dots, return the same array, with the element an int number.

thus #last(n) can return int number, although its end_obj is floating point number,
I think (1...6.3).max returning int 6 is also OK. it can be a rule.

I think the methods' behaviour of Range class should be consistent, when the range contains floating point number.

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