You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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?
Activity
SergeStinckwich commentedon Feb 23, 2021
I dunno what would be the consequences, but it makes sense.
nicolas-cellier-aka-nice commentedon Feb 23, 2021
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
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
isRealNumberand 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
isComplexNumberinstead ofisNumber.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 arcCosand-2 asComplexNumber arcCos.This prevents a Number to answer true to
isComplexNumber, because it won't behaveasComplexNumber...That's sad.
khinsen commentedon Feb 23, 2021
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.
[-]PMComplex should be the subclass of a Number[/-][+]``PMComplex`` should be the subclass of a Number[/+]hemalvarambhia commentedon Apr 23, 2022
Unlike real numbers one cannot directly compare two complex numbers, namely, we can't say
z < wand 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?