``PMComplex`` should be the subclass of a Number

[olekscode]

I don't know if this is easy to do in practice, but this makes a lot of sense to me: A ComplexNumber is a kind of Number

[SergeStinckwich]

I dunno what would be the consequences, but it makes sense.

[nicolas-cellier-aka-nice]

Somehow... Except that inheriting from Number means inheriting from all its expectations. First expectations, is that numbers are an ordered set (Magnitude), that is, they shall respond to <, >, ... There are many ways to order ComplexNumber, but none with this property

a < b & (c < d) ==> (a + c < (b + d))

Also consider other inherited stuff like asPoint. Or not explicitely stated as subclassResponsibility, but systematically sent in arithmetic coercion asInteger, asFloat, ... Consider also chronology stuff days hours minutes ...

Not accounting the expectations of most 3rd party libraries. Until now, x isNumber ==> x isComplexNumber not. So, probably very few will know how to deal with an imaginary part (there are senders in Sound, etc...). Changing this contract is a recipe for trouble. That means that we have to provide a way to test isRealNumber and retrofit most of the 3rd party...

It makes me think of Quaternion, Octonion, ... which are further generalization of Complex. They have less and less algebraic property, Quaternion looses commutativity, Octonion looses associativity, maybe that's why we do not name them Number, unlike Complex... Though they are capable of arithmetic, we do not need to have Quaternion inheritsFrom: Number. Maybe neither do we with Complex?

There is another aspect: currently, Integer can be seen as a Fraction with unit denominator. They appear as perfectly polymorphic with Fraction, though not in the same hierarchy. Why couldn't we have the same, and let Number>>isComplexNumber ^true? This way, 3rd party knowing how to deal with imaginary part would explicitly use isComplexNumber instead of isNumber.

Alas, we made other choices: ComplexNumber with null imaginary part are distinguished from ordinary Number, and are not automatically reduced to real part (unlike a Fraction with unit denominator is reduced to its numerator). This is because, ComplexNumber has a different behavior so as to implement complex extensions of functions. For example, try -2 arcCos and -2 asComplexNumber arcCos. This prevents a Number to answer true to isComplexNumber, because it won't behave asComplexNumber... That's sad.

[khinsen]

I agree with @nicolas-cellier-aka-nice. From a mathematical point of view, insisting on numbers being magnitudes was a big mistake in the Smalltalk class hierarchy.

[hemalvarambhia]

Unlike real numbers one cannot directly compare two complex numbers, namely, we can't say z < w and one criterion we could appeal to is Liskov Substitutability. I don't think Complex Numbers are Liskov Substitutable with the other numbers with respect to comparison (<, <=, >, >=).

I am finding myself aligning with @nicolas-cellier-aka-nice and would hold back from making PMComplex a subclass of Number.

They are certainly fields, and unordered fields at that. Perhaps an avenue to explore?