[Pharo-project] Migrating Complex in a separate package
Hi, Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages. I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk. There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...) - the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value.. What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package... How many of you use Complex ? What do you think of these proposals ? Nicolas
Hi nicolas I would like to have a nice complex package. Do you remember the lengthly discussion that we got in pharo two years ago because the old implementation was not good. I still have the code somewhere. Now if you take the lead on that issue we will follow you. Stef
Hi,
Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages.
I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk.
There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...) - the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value..
What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package...
How many of you use Complex ? What do you think of these proposals ?
Nicolas
I would very much like to see a good complex number package. One thing I do not want to see is -1 sqrt return a complex - it should signal an error. -1 asComplex sqrt will return a complex representing i. In short, we should not coerce integers or floats to complex numbers; one can explicitly do the conversion, which then requests the use of arithmetic and elementary functions for complex numbers. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Monday, October 10, 2011 2:52 PM To: Pharo-project@lists.gforge.inria.fr Cc: The general-purpose Squeak developers list Subject: Re: [Pharo-project] Migrating Complex in a separate package Hi nicolas I would like to have a nice complex package. Do you remember the lengthly discussion that we got in pharo two years ago because the old implementation was not good. I still have the code somewhere. Now if you take the lead on that issue we will follow you. Stef
Hi,
Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages.
I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk.
There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...) - the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value..
What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package...
How many of you use Complex ? What do you think of these proposals ?
Nicolas
On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Hi,
Hi Nicolas,
Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages.
Thank you for bringing up this issue ;-)
I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk.
Yes i think this will be easier for you to have just one package in Squeaksource for Pharo and Squeak.
There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...)
Math-Complex is ok for me.
- the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value..
What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package...
How many of you use Complex ? What do you think of these proposals ?
I'm mostly using Complex and Quaternion for my robotic development. So i want to be able to load these packages in a current Pharo image. Maybe you can merge everything about complex, quaternions (and latter octonions) numbers in a single package in order to avoid too much small packages with just a class (and a test class) ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/
On Mon, Oct 10, 2011 at 08:28:40PM +0200, Nicolas Cellier wrote:
Hi,
Facts: - Complex is present in Squeak trunk image but not used in Kernel - Complex is absent from Pharo image. This breaks portability of some packages.
I suggest putting Complex in its own package in squeaksource. This can work for Pharo alone. I also suggest to optionally remove Squeak.Complex from trunk.
There are then other choices: - the name of the package : can be Complex or Math-Complex (I already put a few Math-* in squeak source...) - the name of the class can be Complex or ComplexNumber Specifically I don't like isComplex, many objects could respond true because complicated; isComplexNumber is much more explicit. We could also think of having complex expressions in a symbolic algebra, and isComplexNumber would be true only for a literal value..
What I could eventually do is publish an old Complex in package Complex for backard compatibility and an updated ComplexNumber in a Math-Complex package...
How many of you use Complex ? What do you think of these proposals ?
I do not use Complex, but I very much like having it in the image because it makes complex arithmetic easy to explore, and makes the system feel more complete. In a way, I think that Complex has more justification for being in the image than Float, because Complex represents fundamental concepts, whereas Float is really just a hardware performance optimization ;) To me it feels natural to have Complex categorized with numbers, but if that makes it harder to support or harder to adopt in other images, then it would not bother me to have it in another package. Changing the name to ComplexNumber would not matter to me, either name would make sense. Thanks! Dave
participants (5)
-
David T. Lewis -
Nicolas Cellier -
Schwab,Wilhelm K -
Serge Stinckwich -
Stéphane Ducasse