Hello,

Le Samedi 10 Juin 2006 22:04, Matej Kosik a écrit :
> Thomas Koenig wrote:
> > Steph, I recommend harvesting Nicolas cellier' fixes.  Certainly in
> > preference to mine (to in elegant) and even in preference to (isNumber
> > ignores issues discussed in Complex class comments.) Nicolas appears to
> > have spent the time working with Complex.  Tom
>
> Hello,
>
> Once upon a time the `Complex' class was in a separate package called
> `Algebraic'. Its intention was to brings things like complex numbers,
> matrices, polynoms and such to the image. Since it was rather
> incomplete, I deleted it. Later someone put these classes into the core
> image.
>

Good idea, and Complex still can easily be separated from base image if we 
want to, because it does not have any user...

However, it's better to maintain Complex-compatible methods in Number 
implemented in base image rather than having to override these methods with 
an algebraic package.
The less we override, the better we feel.

> The problem with the Complex class (and I thought that it was obvious)
> is, that it cannot be implemented correctly without traits. Complex
> certainly is a number (roughly) (you can do arithmetic with it, it plays
> well with other numbers etc). The problem is, that it is not a magnitude
> (they cannot be sensibly totally ordered).
>

Agree and Disagree...
Traits will certainly help factor more code, and it is a good idea to use it 
in algebra.
But i do not see why it would be the only solution to get a correct 
implementation.

> Other things are problematic. If `Complex' is a `Number' then methods:
>
>  to:
>  to:by:
>  to:by:do:
>  to:do:
>  even
>  odd
>  isDivisibleBy:
>  negative
>  positive
>  sign
>  strictlyPositive
>  ceiling
>  detentBy: detent atMultiplesOf: grid snap: snap
>  floor
>  fractionPart
>  integerPart
>  reduce
>  roundTo:
>  roundUpTo:
>  rounded
>  truncateTo:
>  truncated
>
> do not have sense.
>
> Finer classification would be more appropriate, but the whole stuff
> would be a bit more complicated. I am not sure if it could be done
> without traits (I guess).

In VW they have an intermediate class, ArithmeticValue, superclass of both 
Number and Complex, though subclass of Magnitude...
But subclassing is not the only design pattern...
This can be achieved well with isAlgebraic isArithmetic isNumerable 
isNumberExtension or whatever message alike
And yes, Traits can be an elegant way to implement it.

Concerning the question of equality bug, there is another solution: if (1 + 0 
i) would reduce its generality automatically to Number, rather than answering 
a Complex with null imaginary part, then we would not care of comparing 
Number and Complex anymore... However then, Number should implement some 
Complex protocol (like realPart, imaginaryPart, conjugated or whatever...), 
and yes Traits would do it again...

See how Fraction and Integer work, we don't care comparing a (reduced) 
Fraction and an Integer... And Integer canimplement numerator and denominator 
as a special case of Fraction...

I think this approach is used in VW Complex.

Squeak strategy is rather to honour programmer intention to have a memory slot 
for holding Complex value, something more static like say FORTRAN x = (1.,0.)

Both approach have their advantages; i have a slight preference for the 
former, but i'am not sure...

Nicolas