Notes 

(0003726)

nicolas cellier

020806 22:34


I propose a test and a patch.
implement isNumberExtension in Object Complex Number (and future Quaternion Octonion etc... if any).
in = message, test isNumberExtension instead of isNumber.
if false, answer false.
if true, then proceed with current code (will fallback in adaptTo... and succeed).
Rationale:
Complex are Number extension, they can be equal to a number... 


(0003749)

MarcusDenker

021106 19:24




(0004576)

nicolas cellier

032606 21:42


Just to remind that proposed patch also cover this bug:
1 i = nil
(see '[BUG] Complex equality problem' on squeakdev) 


(0004891)

nicolas cellier

050806 10:33




(0007728)

KenD

101906 06:37




(0007737)

nicolas cellier

101906 21:04


Hi Ken.
If you define (Complex>>isNumber ^true), then you suppress the bug, but you might also introduce new bugs for applications expecting only real numbers and testing that using message isNumber...
This is for thess backward compatibility reasons that i introduced a new message.
Alternatively, it would be necessary to add a isRealNumber message to Number, then replace some of the isNumber senders with isRealNumber...
Another reason is that ComplexNumber are not the only Number extensions as shown with my Quaternion example. In order to avoid same bug (1+0i+0j+0k)=0, Quaternion isNumber should also answer true, something that we could agree on, but which sounds less obvious than ComplexNumber (We do not name it QuaternionNumber...). 


(0007739)

KenD

102006 03:45


Hi nicolas,
Exact reals might be implemented as continued fractions, linear fractional transforms... Reals might use interval math, ...
I don't see how having complex numbers not be numbers fixes the case where users of reals numbers expect a floating point representation.
There may be other bugs introduced, but I don't buy the "keep backward compatible bugs" argument. 


(0007742)

nicolas cellier

102006 17:05


Hi again,
1) exact real numbers are out of scope
2) i do not want the bug to survive, but proposed a more local cosmetic change than yours (message isNumberExtension).
Main advantage of my own patch is that it is cosmetic: it has very few chance of breaking current images and applications.
But on longer term, for sure i adhere to the deeper refactorings you are claiming.
The facts:
 isNumber is so far implemented and interpreted as a short cut for (isKindOf: Number).
 Complex is so far not a subclass of Number.
So isNumber is now synonym to (belong to R), and you propose a semantic change (belong to C).
This potentially is dangerous for existing applications. What would you buy for 2 imaginary euros on your bank account?
This is why if we adopt your semantic, we would need a different message telling that imaginary part is null (my isRealNumber proposal which would be true also for Integer and Fraction)
Other facts:
 (2 imaginaryPart) and (1 sqrt) are not understood as Complex extensions
 instead, we have to explicitely create a Complex to obtain this behavior
 For this reason, complex with null imaginary part are not converted automatically to real Number part... (as would a Fraction with denominator 1 being converted to Integer).
If we want to change these behaviours, we should think of all implications, and refactorings it will imply.
I am not sure Complex should be a subclass of Number, considering some details like order relationship #< properties.
Another possibility would be the reverse class hierarchy. Every number is a complex number (eventually with null imaginary part)...
(Abstract)ComplexNumber
(Abstract)(Real)Number
Integer
Fraction
ExactRealNumber
AlgebraicNumber
...
ImaginaryNumber (Complex concrete class)
Maybe AlgebraicNumber should be automatically converted to Fraction when they are rational...
Where to put Float in this hierarchy is not that obvious... Float representation is just a special case of Rational... Except that operations are inexact.
FixedPoint are pure rational with different Display properties...
If we want to introduce Quaternion in such a scheme, we put AbstractQuaternion above AbstractComplexNumber and concrete Quaternion aside AbstractComplexNumber... Something powerfull, but not really lightweight...
Another possibility is to use Traits instead of inheritance...
So my point of view is that just changing isNumber semantic has not enough benefits by itself in order to justify backward compatibility problems it would introduce. Complex maybe deserve deeper changes so as to have a consistant model.
Finally should Quaternion isNumber return true?



(0007743)

KenD

102106 04:27


Ah, I am coming from a background of dynamic languages (Scheme, Lisp, Dylan) where: integer C rational C real C complex.
I am surprised to find someone that thinks differently.
E.g. in the Dylan class hierarchy:
Object

Number

Complex

Real
../..\
Float..Rational
../..........\
....Integer
../............\
single..double..extended
float.....float.....float
What do nonsqueak Smalltalks do? ANSI?

