Bug #15857: <=> の右辺が <=> を実装していない場合の振る舞い

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]
• Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN

[shuujii (Shuji KOBAYASHI)]

<=> の右辺が <=> を実装していないとき、nil が返却される場合と例外が発生する場合があり一貫性がないように思えるのですが、意図的でしょうか。

  0 <=> 0i               #=> NoMethodError (undefined method `<=>' for (0+0i):Complex)
  0 <=> BasicObject.new  #=> nil
 :a <=> 0i               #=> nil
"a" <=> 0i               #=> NoMethodError (undefined method `<=>' for (0+0i):Complex)

なお、0 <=> 0i に関しては、0 == 0i は true になるのでそれとも一貫性がないように思えるのもやや気になりました。

[jeremyevans0 (Jeremy Evans)]

• File complex-real-spaceship.patch complex-real-spaceship.patch added

I agree that this is a bug. Complex#<=> should be implemented, even if it did return nil for all arguments.

However, I think Complex numbers with an imaginary part of zero should be treated as real numbers, and that Complex#real? should return true for such numbers. Likewise, Complex#<=> should return 1, 0, or -1 if both the receiver and the argument are real numbers (treating Complex instances with an imaginary part of zero as real numbers). However, if the receiver or the argument is not a real number, then it should return nil.

Attached is a patch that implements the behavior described above.

[sawa (Tsuyoshi Sawada)]

jeremyevans0 (Jeremy Evans) wrote:

I think [that] Complex numbers with an imaginary part of zero should be treated as real numbers, and that Complex#real? should return true for such numbers.

Changing Complex#real?'s meaning has huge influence. You would also have to change Numeric#integer? for consistency.

Notice that in Ruby, there is no class Real, and real? means "not an instance of Complex". I believe Float is an approximation of the concept of real numbers in mathematics, but unfortunately, Integer and Rational are not subclasses of Float like integers and rational numbers are subsets of real numbers in the mathematical sense. So discussing your proposal in terms of real numbers does not look that helpful.

Complex#<=> should return 1, 0, or -1 if both the receiver and the argument are real numbers (treating Complex instances with an imaginary part of zero as real numbers).

I think this should rather be handled by coercion as with arithmetic operations.

[jeremyevans0 (Jeremy Evans)]

• File complex-real-spaceship-v2.patch complex-real-spaceship-v2.patch added

sawa (Tsuyoshi Sawada) wrote:

jeremyevans0 (Jeremy Evans) wrote:

I think [that] Complex numbers with an imaginary part of zero should be treated as real numbers, and that Complex#real? should return true for such numbers.

Changing Complex#real?'s meaning has huge influence. You would also have to change Numeric#integer? for consistency.

Notice that in Ruby, there is no class Real, and real? means "not an instance of Complex". I believe Float is an approximation of the concept of real numbers in mathematics, but unfortunately, Integer and Rational are not subclasses of Float like integers and rational numbers are subsets of real numbers in the mathematical sense. So discussing your proposal in terms of real numbers does not look that helpful.

Thank you for providing some background on the purpose of the real? method. I agree that it doesn't make sense to change real?. Attached is a patch that only implements <=> and removes the modifications to real?. It also adds specs for <=>.

Complex#<=> should return 1, 0, or -1 if both the receiver and the argument are real numbers (treating Complex instances with an imaginary part of zero as real numbers).

I think this should rather be handled by coercion as with arithmetic operations.

Could you please provide a patch for your approach so we can compare and choose the simpler implementation?

[Eregon (Benoit Daloze)]

The patch looks good to me.

[shuujii (Shuji KOBAYASHI)]

@jeremyevans0 (Jeremy Evans) Thank you for your comment. About Complex, I agree with most of v2 patch, but I have some comments.

• Should methods from Comparable that are currently disabled be enabled?
• rb_undef_method(rb_cComplex, "<=>") is unneeded.
• idCmp can be used instead of id_spaceship.

About other than Complex, <=> of some classes, such as String and Time, will fail if LHSRHS does not implement <=>. It's better to return nil in this case too, because whether it's comparable or not and whether LHSRHS implements <=> or not is essentially irrelevant, I think.

[jeremyevans0 (Jeremy Evans)]

• File complex-real-spaceship-v3.patch complex-real-spaceship-v3.patch added

shuujii (Shuji KOBAYASHI) wrote:

@jeremyevans0 (Jeremy Evans) Thank you for your comment. About Complex, I agree with most of v2 patch, but I have some comments.

• Should methods from Comparable that are currently disabled be enabled?

I don't think so, but I don't have a strong opinion. If you would like those added, please submit a separate feature request for that.

• rb_undef_method(rb_cComplex, "<=>") is unneeded.
• idCmp can be used instead of id_spaceship.

Thank you, I made both of these changes in the attached v3 patch.

About other than Complex, <=> of some classes, such as String and Time, will fail if LHS does not implement <=>. It's better to return nil in this case too, because whether it's comparable or not and whether LHS implements <=> or not is essentially irrelevant, I think.

I agree, but please submit a separate bug report for that as it is unrelated to Complex#<=>.

[shuujii (Shuji KOBAYASHI)]

@jeremyevans0 (Jeremy Evans) Thank you for your comment. About Complex, I agree with most of v2 patch, but I have some comments.

• Should methods from Comparable that are currently disabled be enabled?

I don't think so, but I don't have a strong opinion. If you would like those added, please submit a separate feature request for that.

I don't have a strong opinion, too.

About other than Complex, <=> of some classes, such as String and Time, will fail if LHSRHS does not implement <=>. It's better to return nil in this case too, because whether it's comparable or not and whether LHSRHS implements <=> or not is essentially irrelevant, I think.

I agree, but please submit a separate bug report for that as it is unrelated to Complex#<=>.

Sure. I will create another ticket.

• Status changed from Open to Closed

Applied in changeset git|b9ef35e4c6325864e013ab6e45df6fe00f759a47.

---

Implement Complex#<=>

Implement Complex#<=> so that it is usable as an argument when
calling <=> on objects of other classes (since #coerce will coerce
such numbers to Complex). If the complex number has a zero imaginary
part, and the other argument is a real number (or complex number with
zero imaginary part), return -1, 0, or 1. Otherwise, return nil,
indicating the objects are not comparable.

Fixes [Bug #15857]

[kolbrich (Kevin Olbrich)]

In doing a bit of maintenance work for the ruby-units gem this issue came up. I think there may be some additional methods that now need to be generated in the C code. See the following example.

c = Complex(1,0)
c <=> 1 # => 0
c > 1 # => NoMethodError (undefined method `>' for (1+0i):Complex)
c < 1 # => NoMethodError (undefined method `<' for (1+0i):Complex)
c <= 1 # => NoMethodError (undefined method `<=' for (1+0i):Complex)
c >= 1 # => NoMethodError (undefined method `>=' for (1+0i):Complex)

I would expect these methods to exist and behave in a way that is consistent with the new definition of <=>.