Migrating Complex in a separate package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating Complex in a separate package

Nicolas Cellier
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

Reply | Threaded
Open this post in threaded view
|

Re: Migrating Complex in a separate package

Stéphane Ducasse
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
>


Reply | Threaded
Open this post in threaded view
|

Re: Migrating Complex in a separate package

Schwab,Wilhelm K
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: [hidden email] [[hidden email]] On Behalf Of Stéphane Ducasse [[hidden email]]
Sent: Monday, October 10, 2011 2:52 PM
To: [hidden email]
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
>



Reply | Threaded
Open this post in threaded view
|

Re: Migrating Complex in a separate package

SergeStinckwich
In reply to this post by Nicolas Cellier
On Tue, Oct 11, 2011 at 1:28 AM, Nicolas Cellier
<[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Migrating Complex in a separate package

David T. Lewis
In reply to this post by Nicolas Cellier
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


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Migrating Complex in a separate package

Chris Muller-3
In reply to this post by SergeStinckwich
>>> - 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 have a strong position between Complex and ComplexNumber. I think
> Complex is not that bad.

But I think we should be careful about namespace consumption.
"Complex" is very broad and ambiguous and could potentially create
headaches for other domains that want to define a class named Complex.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Migrating Complex in a separate package

Nicolas Cellier
In reply to this post by Nicolas Cellier
Thanks all for your answers.
Too many words for a single post, so I compiled a few comments and
Complex implementation reflections in this blog entry:
http://smallissimo.blogspot.com/2011/10/about-complex-in-squeak.html

I'm not satisfied with current status because we are mixing two paradigms.
Note that putting Complex outside the image is also an easy solution
for playing with paradigms without causing undesired side effects to
Complex-unaware-Applications.
But maybe it's too easy to divert like this, and we should better
think harder ;)

Nicolas

2011/10/11 Ricardo Moran <[hidden email]>:

>
> On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <[hidden email]> wrote:
>>
>> Juan Vuletich wrote:
>>>
>>> Hi Folks,
>>>
>>> Rodney Polkinghorne wrote:
>>>>
>>>> ...
>>>>
>>>> extra fact:
>>>> - Complex is absent from Cuis
>>>>
>>>
>>> Not for long :) . I have already integrated it and will be in next Cuis
>>> release. I think Complex belongs in the base system.
>>
>> Oh, forgot to say. I also think that
>>   -1 sqrt = 1i
>> should be true, and I'm working on it (together with some other tweaks to
>> #sqrt and friends I'll publish when finished).
>
> +1. I was just about to comment on that one :)
> It always bothered me that "-1 sqrt" wouldn't answer "1i". It seems like an
> incomplete implementation, being that we have the class Complex.
> At the time I "fixed" it by just relying on the fact that the sqrt primitive
> fails when the receiver is negative, but that solution seems very hackish. I
> wonder what your solution looks like? :)
> Cheers,
> Richo
>
>>
>> Thoughts?
>>
>> Cheers,
>> Juan Vuletich
>>
>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: Migrating Complex in a separate package

Nicolas Cellier
Here is a first commit of Squeak/trunk Complex into a separate
Math-Complex package.
This is useful for Pharo users at least.

No rename, no refactoring (but methods #asComplex and
#adaptToComplex:andSend: moved to Number) , just the Squeak version.

Nicolas

2011/10/12 Juan Vuletich <[hidden email]>:

> Nicolas Cellier wrote:
>>
>> Thanks all for your answers.
>> Too many words for a single post, so I compiled a few comments and
>> Complex implementation reflections in this blog entry:
>> http://smallissimo.blogspot.com/2011/10/about-complex-in-squeak.html
>>
>> I'm not satisfied with current status because we are mixing two paradigms.
>>
>> Note that putting Complex outside the image is also an easy solution
>> for playing with paradigms without causing undesired side effects to
>> Complex-unaware-Applications.
>> But maybe it's too easy to divert like this, and we should better
>> think harder ;)
>>
>> Nicolas
>>
>
> Thanks! Good analysis, hard decision.
>
> In any case, I don't think it is needed to have Complex as an external
> package just for the automatic conversion issue. It is enough to have a
> preference.
>
> Cheers,
> Juan Vuletich
>
>> 2011/10/11 Ricardo Moran <[hidden email]>:
>>
>>>
>>> On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <[hidden email]>
>>> wrote:
>>>
>>>>
>>>> Juan Vuletich wrote:
>>>>
>>>>>
>>>>> Hi Folks,
>>>>>
>>>>> Rodney Polkinghorne wrote:
>>>>>
>>>>>>
>>>>>> ...
>>>>>>
>>>>>> extra fact:
>>>>>> - Complex is absent from Cuis
>>>>>>
>>>>>>
>>>>>
>>>>> Not for long :) . I have already integrated it and will be in next Cuis
>>>>> release. I think Complex belongs in the base system.
>>>>>
>>>>
>>>> Oh, forgot to say. I also think that
>>>>  -1 sqrt = 1i
>>>> should be true, and I'm working on it (together with some other tweaks
>>>> to
>>>> #sqrt and friends I'll publish when finished).
>>>>
>>>
>>> +1. I was just about to comment on that one :)
>>> It always bothered me that "-1 sqrt" wouldn't answer "1i". It seems like
>>> an
>>> incomplete implementation, being that we have the class Complex.
>>> At the time I "fixed" it by just relying on the fact that the sqrt
>>> primitive
>>> fails when the receiver is negative, but that solution seems very
>>> hackish. I
>>> wonder what your solution looks like? :)
>>> Cheers,
>>> Richo
>>>
>>>
>>>>
>>>> Thoughts?
>>>>
>>>> Cheers,
>>>> Juan Vuletich
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1410 / Virus Database: 1522/3943 - Release Date: 10/07/11
>>
>>
>>
>>
>
>
>