[3.9] 7033 available

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.

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).

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).
--
Matej Kosik

Ok so could the mathematical guys sync and propose a nice solution  
and let me
know what to do?

Stef


On 10 juin 06, at 22:04, Matej Kosik wrote:

you may want to have a look at the TraitsExample package in the  
Traits repository on SqueakSource (http://www.squeaksource.com/ 
Traits.html).

It contains an implementation of Complex using a trait.

Adrian


On Jun 10, 2006, at 22:04 , Matej Kosik wrote:

Hello,

Le Samedi 10 Juin 2006 22:04, Matej Kosik a écrit :
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.

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