> James Edward Gray II wrote: >> I'm not understanding what I am seeing here. Can anyone please >> explain why the last line of this session gives *false* as an answer? >> >> range = ("1".."10") >> => "1".."10" >> >> range.to_a >> => ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"] >> >> range.member?("1") >> => true >> >> range.member?("2") >> => false >> James Edward Gray II
Daniel Berger wrote: > James Edward Gray II wrote: >> I'm not understanding what I am seeing here. Can anyone please >> explain why the last line of this session gives *false* as an answer?
Daniel Berger wrote: > James Edward Gray II wrote: >> I'm not understanding what I am seeing here. Can anyone please >> explain why the last line of this session gives *false* as an answer? >> <snip>
> I cannot duplicate this with 1.8.2 or 1.8.4.
> - Dan
I'm getting this too. 1 and 10 both return true, everything else returns false.
> James Edward Gray II wrote: >> I'm not understanding what I am seeing here. Can anyone please >> explain why the last line of this session gives *false* as an answer? >> >> range = ("1".."10") >> => "1".."10" >> >> range.to_a >> => ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"] >> >> range.member?("1") >> => true >> >> range.member?("2") >> => false >> James Edward Gray II
> On Jan 13, 2006, at 2:54 PM, Daniel Berger wrote:
>> James Edward Gray II wrote:
>>> I'm not understanding what I am seeing here. Can anyone please >>> explain why the last line of this session gives *false* as an answer? >>> >> range = ("1".."10") >>> => "1".."10" >>> >> range.to_a >>> => ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"] >>> >> range.member?("1") >>> => true >>> >> range.member?("2") >>> => false >>> James Edward Gray II
On Fri, 2006-01-13 at 16:01, Daniel Harple wrote: > Daniel Berger wrote: > > James Edward Gray II wrote: > >> I'm not understanding what I am seeing here. Can anyone please > >> explain why the last line of this session gives *false* as an answer? > >> <snip>
> > I cannot duplicate this with 1.8.2 or 1.8.4.
> > - Dan
> I'm getting this too. 1 and 10 both return true, everything else > returns false.
There was some discussion about this in the recent past. If my memory serves me right (certainly an infrequent happening), the issue that you're running into is that Range#member? is implemented as: class Range def member?(val) if self.exclude_end? (self.first <= val) and (val < self.last) else (self.first <= val) and (val <= self.last) end end end
You should find this in both 1.8.2 and 1.8.4 I think.
> James Edward Gray II wrote: >> I'm not understanding what I am seeing here. Can anyone please explain >> why the last line of this session gives *false* as an answer?
> There was some discussion about this in the recent past. If my memory > serves me right (certainly an infrequent happening), the issue that > you're running into is that Range#member? is implemented as: > class Range > def member?(val) > if self.exclude_end? > (self.first <= val) and (val < self.last) > else > (self.first <= val) and (val <= self.last) > end > end > end
> You should find this in both 1.8.2 and 1.8.4 I think.
This would seem to make it an oddity of String#succ, that behaving automagically, not generating successors with respect to String comparison.
E.g. for any Integers i, i.succ > i. For some strings, that does't hold true.
Bottom line: Don't use strings when you're really using numbers. Like in mathemathical contexts. D'oh. You could possibly hack around that in Range code to provide for data types where generating successors is inconsistent with comparison, but I wouldn't like to see that.
> You could possibly hack around that in Range code to provide for > data types where generating successors is inconsistent with > comparison, but I wouldn't like to see that.
On Fri, 13 Jan 2006 23:00:37 +0100, James Edward Gray II
<ja...@grayproductions.net> wrote: > On Jan 13, 2006, at 3:58 PM, David Vallner wrote:
>> You could possibly hack around that in Range code to provide for data >> types where generating successors is inconsistent with comparison, but >> I wouldn't like to see that.
> It's not too tough in this case:
> >> ("1".."10").to_a.include?("2") > => true
> James Edward Gray II
Yes, that always works, but it beats the point of having first class ranges as opposed to just having a pythonesque range function in the first place. I'd personally rather coerce the strings to numbers if I know they represent such to get more type safety and possibly some execution speed too.
> On Fri, 13 Jan 2006 23:00:37 +0100, James Edward Gray II > <ja...@grayproductions.net> wrote:
>> On Jan 13, 2006, at 3:58 PM, David Vallner wrote:
>>> You could possibly hack around that in Range code to provide for >>> data types where generating successors is inconsistent with >>> comparison, but I wouldn't like to see that.
>> It's not too tough in this case:
>> >> ("1".."10").to_a.include?("2") >> => true
>> James Edward Gray II
> Yes, that always works, but it beats the point of having first > class ranges as opposed to just having a pythonesque range function > in the first place. I'd personally rather coerce the strings to > numbers if I know they represent such to get more type safety and > possibly some execution speed too.
> The rdoc needs to be updated for Range#include? and Range#member? then.
> ~ ryan ~
> On Jan 13, 2006, at 5:13 PM, David Vallner wrote:
>> On Fri, 13 Jan 2006 23:00:37 +0100, James Edward Gray II >> <ja...@grayproductions.net> wrote:
>>> On Jan 13, 2006, at 3:58 PM, David Vallner wrote:
>>>> You could possibly hack around that in Range code to provide for data >>>> types where generating successors is inconsistent with comparison, >>>> but I wouldn't like to see that.
>>> It's not too tough in this case:
>>> >> ("1".."10").to_a.include?("2") >>> => true
>>> James Edward Gray II
>> Yes, that always works, but it beats the point of having first class >> ranges as opposed to just having a pythonesque range function in the >> first place. I'd personally rather coerce the strings to numbers if I >> know they represent such to get more type safety and possibly some >> execution speed too.
> On Sat, 14 Jan 2006 00:17:26 +0100, James Edward Gray II > <ja...@grayproductions.net> wrote:
>> On Jan 13, 2006, at 5:04 PM, David Vallner wrote:
>>> No, those methods work perfectly. The behaviour of String is the >>> problem here.
>> ??? How exactly is it that you believe String should behave?
>> James Edward Gray II
> Well, to work well in Ranges, for any String s, s.succ > s must > hold true.
I'm pretty sure we don't want to change the meaning of String comparisons at this point. succ() just doesn't happened to be defined under those terms, because then it would be a lot less useful to us. It's hard for me to see any of that as "broken".
> Well, to work well in Ranges, for any String s, s.succ > s must > hold true.
How about having Range use Object#strict_succ to generate its sequence? Define String#strict_succ as needed to guarantee s.succ > s and then alias strict_succ to succ for other classes (such as Fixnum) so they don't break when used in a Range.
> On Jan 13, 2006, at 6:54 PM, David Vallner wrote: >> Well, to work well in Ranges, for any String s, s.succ > s must >> hold true.
> How about having Range use Object#strict_succ to generate > its sequence? Define String#strict_succ as needed to guarantee > s.succ > s and then alias strict_succ to succ for other classes > (such as Fixnum) so they don't break when used in a Range.
> Gary Wright
This seems to me to make the problem worse. People expect the values generated by String#succ to be in the array when doing a to_a for instance. I believe the real solution would be to bring back the distinction between member and include (possibly with a new name for the method with the functionality of #member).
On Sat, 14 Jan 2006 01:01:21 +0100, James Edward Gray II
<ja...@grayproductions.net> wrote: > On Jan 13, 2006, at 5:54 PM, David Vallner wrote:
> I'm pretty sure we don't want to change the meaning of String > comparisons at this point. succ() just doesn't happened to be defined > under those terms, because then it would be a lot less useful to us. > It's hard for me to see any of that as "broken".
> James Edward Gray II
I never said anything the like, the code breakage would be inexcusable.
My point is it's String that behaves erreneously in this context and isn't suitable for use in symbolic ranges, not a bug in Range code - the posts were an objection to people wanting to mess up the Range interface.
> On Jan 13, 2006, at 7:18 PM, gwtm...@mac.com wrote:
>> On Jan 13, 2006, at 6:54 PM, David Vallner wrote: >>> Well, to work well in Ranges, for any String s, s.succ > s must hold >>> true.
>> How about having Range use Object#strict_succ to generate >> its sequence? Define String#strict_succ as needed to guarantee >> s.succ > s and then alias strict_succ to succ for other classes >> (such as Fixnum) so they don't break when used in a Range.
>> Gary Wright
> This seems to me to make the problem worse. People expect the values > generated by String#succ to be in the array when doing a to_a for > instance. I believe the real solution would be to bring back the > distinction between member and include (possibly with a new name for the > method with the functionality of #member).
I agree that the change proposed would break Range#to_a for strings, which I can imagine being used. The real solution would be people coding sanely and using Integers to represent integers, and Strings to represent text - using unsuitable data types resulting in a bug is arguably not a language fault.
> This seems to me to make the problem worse. People expect the > values generated by String#succ to be in the array when doing a > to_a for instance. I believe the real solution would be to bring > back the distinction between member and include (possibly with a > new name for the method with the functionality of #member).
It seems strange to want Range to behave like an interval and to also want Range#to_a to create a list of elements that don't all belong in that same interval.
I understand the desire to generate a sequence of strings as defined by the current behavior of String#succ but I don't understand why you would want to use a Range object as a shortcut to that sequence. That particular sequence really has nothing to do with an interval or the ordering defined by String#<=>
On Sat, 14 Jan 2006 01:53:37 +0100, <gwtm...@mac.com> wrote:
> It seems strange to want Range to behave like an interval and to > also want Range#to_a to create a list of elements that don't all > belong in that same interval.
It's a Convenient Hack (tm), and those are extremely hard to weed out once they catch hold. It's the same as when people use #eval that must a nightmare to the brave folks working on optimizing YARV (I want my clean blocks!) instead of the much cleaner metaprogramming facilities in Ruby that let you achieve 99% of what I've seen hacked with evals anyway. (Very obfuscated eval hacks notwithstanding).
