Complex enhancements

[Sija]

• Made Complex descendant of Number (supersedes Let Complex inherit from Number #5436)
• Added Complex#to_* family of conversion methods
• Tweaked docs a bit here & there

[RX14]

I agree with @larubujo. Complex isn't even comparable to itself. It makes little sense for it to descend from Number given Number's current interface.

[Sija]

Complex isn't even comparable to itself.

Hmm, I beg to differ:

crystal/spec/std/complex_spec.cr

Lines 13 to 37 in e04565f

	describe "==" do
	it "complex == complex" do
	a = Complex.new(1.5, 2)
	b = Complex.new(1.5, 2)
	c = Complex.new(2.25, 3)
	(a == b).should be_true
	(a == c).should be_false
	end
	it "complex == number" do
	a = Complex.new(5.3, 0)
	b = 5.3
	c = 4.2
	(a == b).should be_true
	(a == c).should be_false
	end
	it "number == complex" do
	a = -1.75
	b = Complex.new(-1.75, 0)
	c = Complex.new(7.2, 0)
	(a == b).should be_true
	(a == c).should be_false
	end
	end

[RX14]

@Sija

The Comparable mixin is used by classes whose objects may be ordered.

Complex is not ordered.

[Sija]

@RX14 true, yet it's still a Number. All other numeric classes (BigInt, BigFloat, BigRational, BigDecimal) in stdlib derive from Number. IIRC Ruby does the same.

[larubujo]

ruby undefines methods for complex. not such thing in crystal. what do you win with complex < number? what can you do now that you cant before?

[RX14]

@Sija yes complexes are numbers. That doesn't mean it has to inherit Number per se.

If it doesn't fit in the interface for Number, it's not a Number regardless of if it's a number. Yes that points to our number hierarchy being inconsistent with pure mathematics but i'm not sure how important that is in the real world, or if it's worth adding many new interfaces for it like I think Rust has done.

[straight-shoota]

@Sija A complex number is a number in real world (no pun intended). But it does not adequatly qualify as an instance of Number which expects operations that are simply not applicable to complex numbers.
Now, this could mean we need to think about if the features of Number might need a change. But at the current state, it just makes no sense to let Complex inherit from Number.

[Sija]

Fair points, thanks! I understand that, OTOH I see Complex extending Number with arithmetic operations and equality operator, making me ask myself what's the actual difference between them API-wise—spaceship <=> operator?

Perhaps every Number class descendant should inherit Comparable as opt-in instead? Are they any other incompatibilities between their APIs?

What about two other points listed?

[straight-shoota]

The error message should simply describe what's wrong, not how it should be, for example: Complex number with non-zero imaginary part can't be converted to real number.

[Sija]

Changed, thanks!

[ghost]

Going crazy with algebra is probably useless but having Number without <=> and having Conparable as a separate Module makes sense to me.
Finite fields have no ordering as well (F_2={0,1}) and are actually used for coding/ decoding information.
Ruby has Comparable as a module as well although they include it in number directly.
Having conparable as a separate include in every number class that supports it makes sense to me.

In practise for me a number is an element of a field and a field has no inherent ordering.

Someone else might argue though that a pointer to a variable is a number and arguing from this perspective a number is not necessarily a field (you can’t multiply pointers) but you certainly can compare and order their addresses.

[RX14]

I seriously think this is a badly thought out PR trying to shoehorn a Complex into being something it's not: a single-dimensional dumber.

[RX14]

But what's the point of these methods then? Why not just provide an assert_real! and an assert_imaginary! method and let people use c.real? What's the usecase of a number conversion method that raises all the time?

[Sija]

But what's the point of these methods then? Why not just provide an assert_real! and an assert_imaginary! method and let people use c.real? What's the usecase of a number conversion method that raises all the time?

Somehow that's what Ruby does, so I guess all of your questions should be directly answered by digging into the Ruby land, their decision making and API designing process.

I seriously think this is a badly thought out PR trying to shoehorn a Complex into being something it's not: a single-dimensional dumber.

And what's the point of of your criticism? I don't see any constructive arguments, only your personal opinions which you hold dearly to the point of putting yourself on airs.

If it doesn't fit in the interface for Number, it's not a Number regardless of if it's a number. Yes that points to our number hierarchy being inconsistent with pure mathematics but i'm not sure how important that is in the real world, or if it's worth adding many new interfaces for it like I think Rust has done.

AFAIK the only thing from Number API it doesn't fit is <=> operator which IMO shouldn't be included there from default.

[Sija]

Could this PR be re-reviewed?

[Sija]

I reverted the change making Complex a Number descendant.
Could this be re-reviewed?

[Sija]

🏓

[Sija]

No idea why Travis failed...

[RX14]

There's an incorrect sign on the imaginary part, no idea how that happened given the specs are run in the exact same docker container. Nothing could be different between circle and travis!

[Sija]

[...] no idea how that happened given the specs are run in the exact same docker container. Nothing could be different between circle and travis!

I broke CI :( what did I do wrong...? 💭 🐛🔨