How many of you use Complex ?
I do.
Facts:
- Complex is present in Squeak trunk image but not used in Kernel
- Complex is absent from Pharo image.
extra fact: - Complex is absent from Cuis
I think a common Complex library makes sense.
What do you think of these proposals ?
If complex numbers are removed from the image, there's a risk that scientists evaluating Squeak won't find them, and will reject Smalltalk as a result. Complex can't be a library, because it takes special syntax to parse 3+4i. Or so everyone thinks, who hasn't seen Smalltalk.
I think brevity trumps the arguments for ComplexNumber. Rebuttal:
1. Does any other language call them that? Scheme, C, Python and Haskell all say complex.
2. Smalltalk has been used for 30 years. Has there ever been an isComplex method that didn't refer to numbers?
3. All symbolic algebra systems I know about define isKnown, to test for literal values of any type. Users can define isKnownComplex as self isKnown & self isComplex if they want to.
unifying Complex and Point
I think points with non-elemental arithmetic would be too big a change. However, Point>>asArgandComplex and Complex>>asArgandPoint would be useful.
Rodney
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.
I think a common Complex library makes sense.
What do you think of these proposals ?
If complex numbers are removed from the image, there's a risk that scientists evaluating Squeak won't find them, and will reject Smalltalk as a result. Complex can't be a library, because it takes special syntax to parse 3+4i. Or so everyone thinks, who hasn't seen Smalltalk.
I think brevity trumps the arguments for ComplexNumber. Rebuttal:
- Does any other language call them that? Scheme, C, Python and
Haskell all say complex.
- Smalltalk has been used for 30 years. Has there ever been an
isComplex method that didn't refer to numbers?
- All symbolic algebra systems I know about define isKnown, to test
for literal values of any type. Users can define isKnownComplex as self isKnown & self isComplex if they want to.
Agreed wrt class name. But #isComplex has complete different semantics in BorderStyle and ParseNode. I think this is a clear case of "false polymorphism": using the same selector for completely different semantics, that should never be confused. It is better if this selector is changed for three distinct ones, to make the meaning clearer and avoid errors.
unifying Complex and Point
I think points with non-elemental arithmetic would be too big a change. However, Point>>asArgandComplex and Complex>>asArgandPoint would be useful.
Rodney
Haven't made my mind wrt this. Not sure at all.
Cheers, Juan Vuletich
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).
Thoughts?
Cheers, Juan Vuletich
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich juan@jvuletich.org 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
Ricardo Moran wrote:
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <juan@jvuletich.org mailto:juan@jvuletich.org> 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
I don't think it is hackish... It is the usual way for dealing with cases the primitives can't deal. That's totally ok for me.
What I'm trying to fix is that '4 sqrt' and '8 raisedTo: 1/3' answer Floats, when they should answer SmallIntegers.
Cheers, Juan Vuletich
On Tue, Oct 11, 2011 at 10:48 AM, Juan Vuletich juan@jvuletich.org wrote:
Ricardo Moran wrote:
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <juan@jvuletich.orgmailto: juan@jvuletich.org> 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
I don't think it is hackish... It is the usual way for dealing with cases the primitives can't deal. That's totally ok for me.
Mmm... maybe I don't mess enough with primitives to avoid feeling wrong about it :)
What I'm trying to fix is that '4 sqrt' and '8 raisedTo: 1/3' answer Floats, when they should answer SmallIntegers.
Nice! That would allow
(4 sqrt) = (8 raisedTo: 1/3) ----> true
What I would *really* like is some kind of symbolic algebra written entirely in Smalltalk. But I guess it's too much to ask, right? :)
Cheers, Richo
Cheers, Juan Vuletich
Ricardo Moran wrote:
On Tue, Oct 11, 2011 at 10:48 AM, Juan Vuletich <juan@jvuletich.org mailto:juan@jvuletich.org> wrote:
Ricardo Moran wrote: On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich <juan@jvuletich.org <mailto:juan@jvuletich.org> <mailto:juan@jvuletich.org <mailto:juan@jvuletich.org>>> 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 I don't think it is hackish... It is the usual way for dealing with cases the primitives can't deal. That's totally ok for me.Mmm... maybe I don't mess enough with primitives to avoid feeling wrong about it :)
What I'm trying to fix is that '4 sqrt' and '8 raisedTo: 1/3' answer Floats, when they should answer SmallIntegers.Nice! That would allow
(4 sqrt) = (8 raisedTo: 1/3) ----> true
Right.
What I would *really* like is some kind of symbolic algebra written entirely in Smalltalk. But I guess it's too much to ask, right? :)
Cheers, Richo
That would be great, but won't be part of the Number packages, I guess.
Cheers, Juan Vuletich
What I would *really* like is some kind of symbolic algebra written entirely in Smalltalk. But I guess it's too much to ask, right? :)
Not really. Have a look at the FunctionalTalk package.
(Lambda x + 1 - 1) simplified -> Lx.{<x>}
... from there, it's almost trivial (ok, just kidding :)
Stef
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 richi.moran@gmail.com:
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich juan@jvuletich.org 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
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 richi.moran@gmail.com:
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich juan@jvuletich.org 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
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 juan@jvuletich.org:
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 richi.moran@gmail.com:
On Tue, Oct 11, 2011 at 9:51 AM, Juan Vuletich juan@jvuletich.org 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
squeak-dev@lists.squeakfoundation.org
-
Juan Vuletich -
Nicolas Cellier -
Ricardo Moran -
Rodney Polkinghorne -
Stéphane Rollandin