I ran across some code that was trying to validate that an integer
was in a given range, however the integer and the range were Strings.
The problem boils down to this:

    Given that...

    ...it seems like ('1'..'10').member?('2') should return true.  The
problem lies in range.c, in the range_each_func() method.  This method
starts with the first value, then calls succ() to get the next value,
breaking out of the loop when the value is no longer less than or equal
to the ending value (or strictly less than the ending value on an
exclusive range).  Unfortunately, for the given string range this
happens immediately, since '2' > '10'.

    I suppose that it could be argued that this is not a bug, but that
would be a difficult argument to win.  Also, I need to make sure that
this is still a bug in the latest version of Ruby.  Unfortunately, I'm
too sleepy to investigate further or create a patch for this tonight,
but I'll try to work on it some more tomorrow night (assuming nobody
else fixes it first).

Only you can now what the string means, so convert it to an integer
and do the range test on integers.

So I think you should save your time on creating the patch and
preferably fix the application code.

Brian

--
http://ruby.brian-schroeder.de/

irb(main):003:0> ('1.1'..'10.1').each {|s| p s}
"1.1"
"1.2"
"1.3"
"1.4"
..
..
"9.6"
"9.7"
"9.8"
"9.9"
"10.0"
"10.1"
=> "1.1".."10.1"
irb(main):004:0> ('1.6.4'..'1.8.3').each {|s| p s}
"1.6.4"
"1.6.5"
"1.6.6"
"1.6.7"
"1.6.8"
"1.6.9"
"1.7.0"
"1.7.1"
"1.7.2"
"1.7.3"
"1.7.4"
"1.7.5"
"1.7.6"
"1.7.7"
"1.7.8"
"1.7.9"
"1.8.0"
"1.8.1"
"1.8.2"
"1.8.3"
=> "1.6.4".."1.8.3"

I guess it is just impractical for Range#member? to test using #succ.

In message "Re: [BUG] string range membership"
    on Wed, 23 Nov 2005 15:41:32 +0900, "Warren Brown" <warrenbr...@aquire.com> writes:
|    I ran across some code that was trying to validate that an integer
|was in a given range, however the integer and the range were Strings.

include? and member? compares with beg <= val <= end, which is
dictionary order for strings.  Unfortunately strings generated from
using succ is not in dictionary order.  I'm not sure how to solve
this.

  def cmp(other)
    return -1 if length < other.length
    return 1 if length > other.length
    self <=> other
  end

Of course this won't be of use to tuple forms like "1.18.12", but in
such cases a Tuple object is in order anyway.

    This shows a clear and unique mapping of the range '1'..'10' into a
set of strings.

regards.

In message "Re: [BUG] string range membership"
    on Wed, 23 Nov 2005 23:57:41 +0900, "Warren Brown" <warrenbr...@aquire.com> writes:

|> I'd argue that it is not a bug, as there is no unique
|> isomorphie from strings to integers.
|
|    I have to disagree.

For your information, member? used to iterate over items to check
membership.  But since confusion between include? and member?, they
were merged.  The point is Ranges are used both for ranges and
intervals.  Sometimes users want it to behave like a range surrounded
by begin/end values.  Sometimes they want it to behave like a set of
values, that #each produces.

I'd like to care this issue, but I haven't know the right way to solve
it yet.  Perhaps we should provide both membership method, with right
names for each.  Any ideas?

    Don't let the fact that my example used strings that look like
numbers confuse the issue.  The issue is that a range of strings that
can be converted into a finite set, has a method to test for membership
in that range, that doesn't match values that are in the set.  Wow, that
sentence is even hard for *me* to follow.

    OK, let's take a different example to avoid all discussion of
integers and various string representations of them.

    Here we have a string range that has 27 "members".  Now:

    Can this really be called correct behavior of the member?() method?
I can't see any tenable argument to say that it is.

ruby -e "p %w(1 10 11 100 101).map { | b | b.to_i(2) }"
[1, 2, 3, 4, 5]

is another mapping of strings to integers that is equally valid (and
would not contain '5').

Brian

--
http://ruby.brian-schroeder.de/

irb(main):001:0> s = 'z'
=> "z"
irb(main):002:0> s < s.succ
=> false

    Because of that, there is a huge distinction between
str_range.to_a.member?(x) (is x a member of the set of the range's
values) and (str_range.first <= x <= str_range.last) (is x in the
range's interval).  
So, given that (at least in the case of ranges of strings) there is a
clear distinction between a value being included in the interval and a
value being included in the set, it appears that we have a real need for
two different methods.  The methods Range#include? (in interval) and
Range#member? (of set) seem to be perfect candidates for these two
different functionalities.  Before these two methods were merged, did
they take on these two functionalities, or were they different in some
other way?

    Are there other cases where "membership" changes depending on
whether the range is viewed as a set or an interval?  If not, perhaps it
would be better to address the fact that str.succ violates the (str <
str.succ) assumption.  Perhaps the functionality currently in
String#succ could be moved to another method (String#increment
perhaps?), and String#succ could take on a new functionality that does
not violate (str < str.succ).

    Anyway, please let me know if there is anything I can do to help
settle this issue.

my point is simply that you seem to be merging the notion of ranges and sets.
the range abstract to_a is determined by only a few things

   - the start and end points

   - the succ method of the start value and each successive succ value
     remember one could do this

       irb(main):003:0> class String; def succ; self == "1" ? 42 : super; end; end
       => nil
       irb(main):004:0> "1".succ
       => 42

   - the spaceship operator for each succ value called against the endpoint

because of this we cannot even safely call to_a on an arbitrary range., for instance

   irb(main):002:0> (42.0 .. 1.0).to_a
   TypeError: can't iterate from Float
    from (irb):2:in `each'
    from (irb):2:in `to_a'
    from (irb):2

in summary a range is nothing but a set of endpoints with some
abstract/duck-type-like methods that may or may not produce a set as a
__process__.  note that the set produced is not part of the range itself and
can be dynamically altered or even be made to produce a different set each
time:

   harp:~ > cat a.rb
   class Float
     def succ
       self + rand
     end
   end

   p((4.2 ... 42.0).to_a)

   harp:~ > ruby a.rb
   [4.2, 4.60303889967309, 5.57983848378295, 6.19446672151043, 6.92731328072508, 7.40446684874589, 7.79202463038348, 8.67552806421286, 9.42821837951244, 10.1988047216007, 11.1116769865281, 11.6169205995556, 11.9975653524073, 12.2256247650959, 12.8874200335378, 13.1557666607712, 13.6470070004444, 14.2172959192607, 15.0882979655236, 15.3487930162798, 15.9791460692026, 16.4321713791994, 17.0903318945661, 17.2967949864209, 18.2400722395741, 18.7286500286255, 19.7174743954199, 20.4528553779707, 20.953553149678, 21.0415866875269, 21.2924876748544, 22.2378099442685, 23.0076932295775, 23.0941582708386, 23.4748092012559, 23.5515124737304, 24.3463511761819, 24.6901201768951, 25.2541406207396, 26.0256212044938, 26.843159468986, 26.9579528629072, 27.01297383827, 27.7250436963749, 27.9017308958297, 28.1100643283236, 28.4480522935525, 28.6197629801695, 29.3756706791326, 29.9897540116082, 30.0057580759777, 30.7085039121469, 30.7510332074171, 30.9096299847723, 30.9314941316772, 31.3964098461468, 31.7312966347497, 32.2153802510432, 32.619498970957, 32.9731525439908, 33.3765950052407, 34.3397676884718, 35.1641816525327, 35.4891756054474, 36.2408178073905, 36.8733362068042, 37.6251560883057, 37.8047618263845, 37.8828752584342, 38.2001976403303, 38.9255502197319, 39.8027872575378, 40.0416710479264, 40.9954826039753, 41.4534375661544]

   harp:~ > irb
   irb(main):001:0>  'z' < 'aa'
   => false

ergo - not in the set.  the confustion here is caused by exactly the reasons
i'm explaining - String#succ has been defined not to create a monotonically
increasing (<=>) sequence - but to produce the "next" string in an english
sense.  this is very useful for auto-generating names

   irb(main):004:0> "z99".succ
   => "aa00"

if this were a monotonically increasing set the output would be

   => "z9:"

but that sure isn't that useful - unless you want to try to use ranges as
sets.

the secret here is simply re-define String#succ - not Range#member.  if
String#succ did a simply addition using base 255 arith you'd be set.

kind regards.

I'm not sure everyone understood me though. The problem is that
String's #<=> and #succ methods are not compatible. Therefore
Range#member? and Rage#include? which use #<=> can not provide proper
results for String-based Ranges. The solution is to have Range use a
different comparision method, namely #cmp. In most classes #cmp will of
course just be an alias for #<=>, but it String is would differ to be
compatible with #succ, and then #include and #member would be correct.
Q.E.D.

In message "Re: [BUG] string range membership"
    on Thu, 24 Nov 2005 01:03:19 +0900, "Warren Brown" <warrenbr...@aquire.com> writes:

|So, given that (at least in the case of ranges of strings) there is a
|clear distinction between a value being included in the interval and a
|value being included in the set, it appears that we have a real need for
|two different methods.  The methods Range#include? (in interval) and
|Range#member? (of set) seem to be perfect candidates for these two
|different functionalities.  Before these two methods were merged, did
|they take on these two functionalities, or were they different in some
|other way?

#include? used for range check, #member? was for set membership.  But
since they have same functionality in Enumerable, some claimed having
different behaviors in Range was confusing.  I agreed.

|    Anyway, please let me know if there is anything I can do to help
|settle this issue.

All we need is making up good names for each functionality.

??

In message "Re: [BUG] string range membership"
    on Thu, 24 Nov 2005 09:38:11 +0900, "Ara.T.Howard" <ara.t.how...@noaa.gov> writes:

|> All we need is making up good names for each functionality.
|
|   Range#contains?
|
|??

For which functionality?

The overarching issue is that sortable and comparable are using the
same method #<=>, but they do not neccessarily want the same meaning.
You should provide a separate method for comparable --like I said, in
most cases they will be equivalent, but not so in String. And
dictionary order comparion is needed anyway. I studied this issue
exahustively over a year ago when I wrote a true Interval class.

   harp:~ > cat a.rb
   module Enumerable
     def contains? value
       map.include? value
     end
   end

   r = "a" .. "aa"
   p r.contains?("z")

   harp:~ > ruby a.rb
   true

so, if each would 'hit' it - it's contained.

kind regards.

In message "Re: string range membership"
    on Thu, 24 Nov 2005 11:07:26 +0900, "Trans" <transf...@gmail.com> writes:

|> All we need is making up good names for each functionality.
|
|That is NOT all you need! This does not solve the complete problem, but
|only provides a little-bitty patch for query on a Range member, and a
|very inefficient one at that --which I thought was part of the reason
|you changed #include and #member to be the same in the first place.

Depends on how you define problem.

|The overarching issue is that sortable and comparable are using the
|same method #<=>, but they do not neccessarily want the same meaning.
|You should provide a separate method for comparable --like I said, in
|most cases they will be equivalent, but not so in String. And
|dictionary order comparion is needed anyway. I studied this issue
|exahustively over a year ago when I wrote a true Interval class.

I'm not sure what you meant here.  Range has no relation with
sorting.  Can you elaborate?

Then consider that Range is not a true interval because it uses #succ.
This is why I created a true Interval class that uses #+ instead.
Likewise Range shouldn't use #<=> either, but another method, lets call
it #cmp. This would fix the problem.

In general:

  module Comparable
    def cmp(o)
      self<=>o
    end
  end

That is to say, for anything comparable #cmp is the same as #<=>,
unless otherwise defined. (Alternately you could define #cmp as an
alias of #<=> directly in the classes it is needed --that would
probably be better.) Then in String define #cmp specially to confom to
the successive order as defined by #succ.

Thus having Range use #cmp instead of #<=> the issue is solved.

In summary, an object would then be "Rangeable" if it supports #succ,
but only fully so if is also supports #cmp too (instead of #<=>).

Does it make sense now? (Sorry if I'm not explaining well, it's a tad
subtle and it's been awhile since I worked on it too, so I have been
trying to recall it all myself too).

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/167200

  "not quite - we have a string range that __produces__
   27 elements.  it does not 'have' or 'contain' them.
   it merely suggests this set as it's current thought"

(SCNR ;)

Would something like Range#covers? be more apt?
(meaning within the bounds).
Oh, pooh, that's got an 's' on the end as well :(