Numeric <=>

[ChrisH]

Just looking at the docs on ruby-doc.org and noticed that Numeric
implements <=> so it returns 0 or nil. It also includes Comparable,
which depends on <=> returning -1, 0 or 1. Any one know why
Numeric doesn't provide all three expected values?

Cheers
Chris

 

[Eric Hodel]

Just looking at the docs on ruby-doc.org and noticed that Numeric
implements <=> so it returns 0 or nil. It also includes Comparable,
which depends on <=> returning -1, 0 or 1. Any one know why
Numeric doesn't provide all three expected values?

Numeric is an abstract class. Fixnum, Bignum, Float, BigDecimal, etc
need to override #<=> appropriately.

 

[ChrisH]

Thanks Eric. I just wonder why Numeric doesn't implement it properly?
Is it implented this way because Comparable requires it, but since
Numeric is Abstract it doesn't need to actually work?

This is just idle curiosity, but any insight is appreciated

Cheers

 

[Christophe Grandsire]

Thanks Eric. I just wonder why Numeric doesn't implement it properly?

Probably because it can't. I'm not completely up-to-date with the Numeric
inheritance chain, but I guess for instance Complex numbers also inherit =
from
Numeric. Being Numeric doesn't necessarily mean that there is a meaningfu=
l
order among the objects.

Then again, I'm out on a limb here, and may be completely wrong.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Robert Klemme]

Probably because it can't. I'm not completely up-to-date with the
Numeric inheritance chain, but I guess for instance Complex numbers
also inherit from Numeric. Being Numeric doesn't necessarily mean
that there is a meaningful order among the objects.

Although I agree with your analysis that Numeric can't properly implement
<=> the question remains why <=> is actually implemented in Numeric. ATM
I cannot see what necessitates it. Including Comparable is not a reason
IMHO because that will break either way (i.e. with missing <=> and with

Then again, I'm out on a limb here, and may be completely wrong.

Not completely but I have the feeling we're still not there. Someone
probably needs to take the time and have a look at the sources...

Kind regards

robert

 

[Eric Hodel]

Although I agree with your analysis that Numeric can't properly
implement
<=> the question remains why <=> is actually implemented in
Numeric. ATM
I cannot see what necessitates it. Including Comparable is not a
reason
IMHO because that will break either way (i.e. with missing <=> and
with


Not completely but I have the feeling we're still not there. Someone
probably needs to take the time and have a look at the sources...

If you forget to define #<=> in your Numeric subclass you have a
safety net and your code won't mysteriously die.

 

[daz]

Although I agree with your analysis that Numeric can't properly implement
<=> the question remains why <=> is actually implemented in Numeric. ATM
I cannot see what necessitates it. Including Comparable is not a reason
IMHO because that will break either way (i.e. with missing <=> and with


Not completely but I have the feeling we're still not there. Someone
probably needs to take the time and have a look at the sources...

#-------------
class Roo < Numeric; end

a = Roo.new
b = Roo.new
c = a

p a <=> b #-> nil
p a <=> c #-> 0
#-------------

Well, that's helpful!

Ruby (like me) hasn't a clue what a 'Roo' is,
but it's able to tell that a == c which might
be enough to keep a routine running.


<Changelog>
Wed Nov 20 01:52:21 2002 Yukihiro Matsumoto <[email protected]>

* numeric.c (num_cmp): added to satisfy Comparable assumption.
</>

http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/numeric.c.diff?r1=1.59;r2=1.60;f=h


daz

 

[Robert Klemme]

#-------------
class Roo < Numeric; end

a = Roo.new
b = Roo.new
c = a

p a <=> b #-> nil
p a <=> c #-> 0
#-------------

Well, that's helpful!

Ruby (like me) hasn't a clue what a 'Roo' is,
but it's able to tell that a == c which might
be enough to keep a routine running.

Definitely not:
ArgumentError: comparison of Roo with Roo failed
from (irb):14:in `sort'
from (irb):14
from :0
ArgumentError: comparison of Roo with Roo failed
from (irb):21:in `<'
from (irb):21
from :0

This is what happens in the "standard cases".
NoMethodError: undefined method `<=>' for #<Bar:0x10182360>
from (irb):20:in `sort'
from (irb):20
from :0

NoMethodError: undefined method `<=>' for #<Foo:0x1018bc60>
from (irb):17:in `sort'
from (irb):17
from :0

<Changelog>
Wed Nov 20 01:52:21 2002 Yukihiro Matsumoto <[email protected]>

* numeric.c (num_cmp): added to satisfy Comparable assumption.

Hm... Doesn't sound as if the assumption was satisfied...
http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/numeric.c.diff?r1=1.59;r2=1.60;f=h

Kind regards

robert

 

[daz]

Definitely not:

ArgumentError: comparison of Roo with Roo failed

Those instances are all different. The change only helps
by detecting equality, which is possible when a == a:

class Roo < Numeric; end
a = Roo.new
p [a,a].sort # [#<Roo:0x264a66c>, #<Roo:0x264a66c>]

- Better than:
"I can't sort these, I don't know what they are."

Hm... Doesn't sound as if the assumption was satisfied...

Nothing deep here, I think - just a tiny kink removed :-?


daz

 

[Robert Klemme]

Those instances are all different. The change only helps
by detecting equality, which is possible when a == a:

But for detecting equality there's already == and eql?. And these methods
are used where equality is needed (namely in a hash). No need to have a

class Roo < Numeric; end
a = Roo.new
p [a,a].sort # [#<Roo:0x264a66c>, #<Roo:0x264a66c>]

- Better than:
"I can't sort these, I don't know what they are."

I beg to differ: IMHO it's better to make this case raise an error because

Nothing deep here, I think - just a tiny kink removed :-?

Kind regards

robert