From: Brian Candler <B.Candler@...>
Date: 2004-10-09T19:52:55+09:00
Subject: Re: Range behavior (Re: [RCR] New [] Semantics)

On Sat, Oct 09, 2004 at 07:30:09PM +0900, Randy W. Sims wrote:
> Ahh, ok. I didn't realize set

Range

> was implemented in this way. I can see why 
> you did it: it allows ranges for all types of objects. Very nice.

Range#include? just uses the <=> operator to test for the bottom and top of
the range (in other words, it's intended for objects which are Comparable
rather than Enumberable)

> Even with this, It would still be nice if membership could be tested... 
> efficiently. Or at least efficient for the common cases. Range could be 
> special cased for Integers so that a member could be found by 
> calculating elements for a "binary search" (if (((end - start) / 2) > 
> target))...

You can't do a binary search over an Enumberable, because it just gives you
the elements one at a time in order; it doesn't support "fetch Nth item".
You'd have to first enumerate everything into an Array, which brings you
back to the current situation anyway.

Also, if you really want that sort of membership test with integers, then
there's no need for a binary search anyway:

     myrange.include?(x) and x.to_i == x

ISTM that in Ruby, a range is *primarily* a continuous range with lower and
upper bounds. If the lower bound happens to be an object which responds to
'succ' to generate the next object in a sequence, and <=> to match the upper
bound, then magically it also becomes Enumerable.

Regards,

Brian.