Complex Solutions

Greetings,

I have released SLICE-basic-Complex to PharoInbox and created added ISSUE #
1097.

I believe this proposal addresses most of the concerns I have seen.  

Thanks again for your review and helpful comments!

A brief discussion follows.

-KenD
=====================================

The SLICE-basic-Complex package (re)adds Complex objects to the Pharo Beta 1
image.  

YOU MUST LOAD the SLICE-remove-Complex package BEFORE LOADING THIS PACKAGE !!


==PROBLEMS==

In mathematics, type Complex is a superset of type Real, but in Pharo the
class Complex is unrelated to subclasses of Number.  This causes some common
expectations to be disappointed.  In particular, the following patterns break
down:

  [1]  If (A=a) and (B=b) and (A<B) then (a<b)
  [2]  A squared sqrt = A
  [3]  A isNumber => (A class) isKindOf: Number
  [4]  Pharo users and code have expectations that (-1 sqrt) causes an
exception.

[1] | A a B b |
  A := 0.
  a := A + 0i.
  B := 1.
  b := B asComplex.
  A = a. "true"
  B = b. "true"
  A < B. "true"
  a < b. "ERROR"

[2]
    1i squared. "-1 + 0i"
    1i squared sqrt. "ERROR"
    1i squared real sqrt. "ERROR"

[3] (1.2 + (1/2)i) isNumber. "true"
    (1.2 + (1/2)i) class isKindOf: Number. "false"

In particular, isNumber is used in a number of low-level methods which would
not deal well with complex numbers.

E.g. FloatArray>>
 *= anObject
        ^anObject isNumber
                        ifTrue:[self primMulScalar: anObject asFloat]
                                        ifFalse:[self primMulArray: anObject]
                                                               
                                       
==SOLUTIONS==
                                       
[A] SLICE-remove-Complex

Removing the Complex code gives more traditional Smalltalk expectations.  In
particular this conservative approach yields the best code backward
compatability because Complex is a relatively recent addition to Squeak and
was not present in many older Smalltalk implementations.  In particular,
problems [1][2][3] cannot arise.


[B] SLICE-basic-Complex

[1] is fixed by adding a "formal" method to Complex with selector #< which only
compares real numbers (those whose imaginary component is zero).

[2] is addressed by keeping Complex objects disjoint from Numbers.  
Explicit coercion is required
  1i squared asComplex sqrt -> 1i
  -4 asComplex sqrt -> 2i
  The examples shown above continue to yield exceptions.

[3] Complex objects are NOT numbers, but objects with number-like behavior.
Complex instances answer false to isNumber.  There is a isNumberOrComplex
predicate which is used in the Number>>= methods in place of isNumber so that
the double dispatch coercions work as expected with Numbers and Complex
instances.


Note that the basicComplex package also adds the hyperbolic trig functions to
Numbers.


-KenDickey  [Ken dot Dickey at Whidbey dot Com]


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ken,

I have not been over all of it, but I have found that Real>>arcCosH and #arcTanH can answer a Complex.  I would rather not have to say it, but I do not get the sense that you have taken our concerns seriously.  We want the errors from Float when the domains are violated.  A mere #asComplex can be dividing line that puts the programmer in conrol.

On this next minor point I can be talked out of it, but I would much prefer #cosh etc. to #cosH; it's easier to type and matches all conventional notation that I have seen.

Number>>angle should probably be called #argument, though I would argue that it should not exist as it is another example of implicit (however benign) coercion to complex numbers.

Complex>>angle looks like it will answer zero for a value of zero??  AFAIK, there should be no direction for a zero vector.  In a way, it is splitting hairs because exact comparisons of floats are dubious, but it probably should raise an error for zero.

Object Arts has long looked down on #as* and #is* methods.  With my bias toward their views confessed, #isComplex and #isNumberOrComplex realy should not exist, and even if they do, what are they doing in Object?  #isNumberOrComplex raises concerns that there is too much blending of Complex into floats.

There are various uses of Taylor series corrections and some things that are computed directly in terms of exponentials.  My hunch is that robust scientific libraries will (hopefully) do these things well, and most of the transcendental functions, especially over complex numbers, should come from them when possible and reasonable.  The results will likely be faster and probably more accurate than what we can do in Smalltalk.

Bill


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Ken Dickey
Sent: Saturday, August 29, 2009 11:08 AM
To: [hidden email]
Subject: [Pharo-project] Complex Solutions

Greetings,

I have released SLICE-basic-Complex to PharoInbox and created added ISSUE # 1097.

I believe this proposal addresses most of the concerns I have seen.  

Thanks again for your review and helpful comments!

A brief discussion follows.

-KenD
=====================================

The SLICE-basic-Complex package (re)adds Complex objects to the Pharo Beta 1 image.  

YOU MUST LOAD the SLICE-remove-Complex package BEFORE LOADING THIS PACKAGE !!


==PROBLEMS==

In mathematics, type Complex is a superset of type Real, but in Pharo the class Complex is unrelated to subclasses of Number.  This causes some common expectations to be disappointed.  In particular, the following patterns break
down:

  [1]  If (A=a) and (B=b) and (A<B) then (a<b)
  [2]  A squared sqrt = A
  [3]  A isNumber => (A class) isKindOf: Number
  [4]  Pharo users and code have expectations that (-1 sqrt) causes an exception.

[1] | A a B b |
  A := 0.
  a := A + 0i.
  B := 1.
  b := B asComplex.
  A = a. "true"
  B = b. "true"
  A < B. "true"
  a < b. "ERROR"

[2]
    1i squared. "-1 + 0i"
    1i squared sqrt. "ERROR"
    1i squared real sqrt. "ERROR"

[3] (1.2 + (1/2)i) isNumber. "true"
    (1.2 + (1/2)i) class isKindOf: Number. "false"

In particular, isNumber is used in a number of low-level methods which would not deal well with complex numbers.

E.g. FloatArray>>
 *= anObject
        ^anObject isNumber
                        ifTrue:[self primMulScalar: anObject asFloat]
                                        ifFalse:[self primMulArray: anObject]
                                                               
                                       
==SOLUTIONS==
                                       
[A] SLICE-remove-Complex

Removing the Complex code gives more traditional Smalltalk expectations.  In particular this conservative approach yields the best code backward compatability because Complex is a relatively recent addition to Squeak and was not present in many older Smalltalk implementations.  In particular, problems [1][2][3] cannot arise.


[B] SLICE-basic-Complex

[1] is fixed by adding a "formal" method to Complex with selector #< which only compares real numbers (those whose imaginary component is zero).

[2] is addressed by keeping Complex objects disjoint from Numbers.  
Explicit coercion is required
  1i squared asComplex sqrt -> 1i
  -4 asComplex sqrt -> 2i
  The examples shown above continue to yield exceptions.

[3] Complex objects are NOT numbers, but objects with number-like behavior.
Complex instances answer false to isNumber.  There is a isNumberOrComplex predicate which is used in the Number>>= methods in place of isNumber so that the double dispatch coercions work as expected with Numbers and Complex instances.


Note that the basicComplex package also adds the hyperbolic trig functions to Numbers.


-KenDickey  [Ken dot Dickey at Whidbey dot Com]


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project