A bug in ranges?

I think I may have stumbled upon a minor bug in ranges.

on my system,

("Z".."AA").map returns []

while

"Z".succ returns "AA"

"Z".upto("AA") also returns []

ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1]

Is this a real bug, or am I expecting behavior that really shouldn't be
there?

_Kevin

···

--
Posted via http://www.ruby-forum.com/.

Character ranges act funny, is all. You're expecting odd behaviour, really.

-austin

···

On 5/28/06, Kevin Olbrich <kevin.olbrich@gmail.com> wrote:

I think I may have stumbled upon a minor bug in ranges.
("Z".."AA").map returns
while
"Z".succ returns "AA"
"Z".upto("AA") also returns

Is this a real bug, or am I expecting behavior that really shouldn't be
there?

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

By looking at the definition of the Range class
http://www.ruby-doc.org/core/classes/Range.html
- please note that x..y is the same as Range.new(x,y) -
one can conclude that Ranges are constructed using <=> and .succ.
While it is true that "Z".succ == "AA" it is also true that "Z" <=> "AA" is
implying "Z">"AA" and
therefore Range("Z".."AA") seems correctly empty.

What might come as a surprise is that you have found a ruby object that is
greater than its successor but that depends on the kind of *order* we are
dealing with. This oddness comes from String, not from Range though. By
carefully looking at the definition of succ and <=> in String one can ask
oneself if constructing Ranges from Strings is very useful in all contexts
because <=> and succ do not seem to be desinged for the same view of the
String domain.

BTW what do you think ("AA".."Z").to_a delivers (should be infinite by the
same reasoning, should it not?).

It seems therefore that some classes are not made to be used for Ranges
although they are Compareable and Enumerable which is not very reassuring. I
guess you just opened Pandorra's can :frowning:

Maybe that is because it was not clear that "<=>" and "succ" depend on each
other by the design of the language and as they are used for other things
"<=>" for Compareable one could argue that we have too closely coupled
bahvior here. And while one could argue so, I do! Different methods should
be used to define Range (e.g. range_smaller?, range_next).

Cheers
Robert

···

On 5/28/06, Kevin Olbrich <kevin.olbrich@gmail.com> wrote:

I think I may have stumbled upon a minor bug in ranges.

on my system,

("Z".."AA").map returns

while

"Z".succ returns "AA"

"Z".upto("AA") also returns

ruby 1.8.4 (2005-12-24) [i686-darwin8.6.1]

Is this a real bug, or am I expecting behavior that really shouldn't be
there?

_Kevin

--
Posted via http://www.ruby-forum.com/\.

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein

Just another point which is troubling:

irb(main):025:0> ("Z".."AA") === "Z"
=> false
irb(main):026:0> ("AA".."Z") === "Z"
=> true

and

irb(main):030:0* ("AA".."Z") === "Z"
=> true
irb(main):031:0> ("AA".."Z") === "AA"
=> true
irb(main):035:0> ("AA".."Z") === "AB"
=> trueirb(main):036:0> ("AA".."Z") === "A"*1764
=> true

Robert Dober wrote:

Just another point which is troubling:

irb(main):025:0> ("Z".."AA") === "Z"
=> false
irb(main):026:0> ("AA".."Z") === "Z"
=> true

and

irb(main):030:0* ("AA".."Z") === "Z"
=> true
irb(main):031:0> ("AA".."Z") === "AA"
=> true
irb(main):035:0> ("AA".."Z") === "AB"
=> trueirb(main):036:0> ("AA".."Z") === "A"*1764
=> true

I put together a short class to do LetterSeries. It implements <=> and
succ in a way that lets it act correctly in a range object.

http://www.sciwerks.com/blog/2006/05/28/ruby-series-az/

···

--
Posted via http://www.ruby-forum.com/\.

Just an FYI, this general topic of ranges and strings has been
discussed extensively in the recent past:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/cfc720a7a0313323/9d17db883a1d6100
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/2d6a59a136abce3d/ccf66936477e73a7

Ryan

pointer.
It seems to me, and that is eventually a clear statement from my side ;),
that this needs more discussion.
Please kindly try to forget what I have written sofar - because of the noise
- and evaluate the following statement.

It is bad that Range builds its behavior upon <=> and succ, because <=> and
succ are not designed (not always at least) to work together for that
purpose.
I conclude from Matz' post that this confusion could be clarified by
redesigning Range to be build on a contract that does not interfere with
other contracts. Changing the paradigme.

I am well aware that such a redesign might have more impacts ( for logical
compatibility with the Enumerable mixin f.i.) than one might think of at
first sight but the OP's confusion and the previous discussion make it quite
clear to me...

Thanks for listinening.

Robert

···

On 5/29/06, Ryan Leavengood <leavengood@gmail.com> wrote:

Just an FYI, this general topic of ranges and strings has been
discussed extensively in the recent past:

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/cfc720a7a0313323/9d17db883a1d6100

http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/2d6a59a136abce3d/ccf66936477e73a7

Ryan

Sorry if my confused post did not help to pass my point, thx also for the

--
Deux choses sont infinies : l'univers et la bêtise humaine ; en ce qui
concerne l'univers, je n'en ai pas acquis la certitude absolue.

- Albert Einstein