Begin forwarded message:
From: "Schwab,Wilhelm K" <bschwab@anest.ufl.edu> Date: August 18, 2009 2:09:15 AM CEDT To: "Ken.Dickey" <Ken.Dickey@whidbey.com> Cc: Stéphane Ducasse <stephane.ducasse@inria.fr> Subject: RE: REPOST: Complex Solution Outline
Ken,
Please put this on the wiki; we try to keep the process transparent. As should be no surprise by now, I question the value of $< for complex numbers - I just don't see the point of defining one that works so infrequently as this, and I see reasons not to offer one at all. People knowing their way around floating point math and applications of complex variables will know what to do for any given comparison based on physical motivations.
Removing things and making packages seems (Stef?) to be a general approach to cleaning, so I doubt there will be resistance to that idea.
I think the extended complex solution is risky. That is not to say you should not write it and use it, but it should be separate and clearly marked with caveats; I can speak only for myself (and probably for Sig), but I would *not* want it in my image. Much of what you have expressed as concerns about the current implementation involves yet another dimension, which is treating the few "nice" numbers that exist without roundoff error; it would be an exact and/ or symbolic package. I think it would yield very little benefit from a LOT of work, but you seem to care about it, so it should probably be described. Even if it never gets built, giving it a name would help sort out the various feature demands.
Finally, there is a lot that should be added to this. There should be a GSL or similar FFI or plugin and wrappers to bring the elementary and special functions into Pharo. That is actually bigger than just complex numbers, so it probably deserves its own wiki page and plan.
Bill
-----Original Message----- From: Ken.Dickey [mailto:Ken.Dickey@whidbey.com] Sent: Monday, August 17, 2009 6:14 PM To: Schwab,Wilhelm K Subject: REPOST: Complex Solution Outline
Bill,
Feedback appreciated.
Thanks, -KenD VVV==============unComplex.txt================VVV INTRODUCTION
The current Complex class is not carrying its weight in the Pharo- Core image. It appears to be little used and has some serious integration problems with the numeric classes.
This proposal has three parts, removeComplex, basicComplex, and extendedComplex.
The removeComplex package removes the Complex class and associated code from the current (beta1) image.
The basicComplex package adds Complex back with some additional changes to fix some of the integration problems, but leaves out some mathematical properties to assure backward compatability.
The extendedComplex package makes the Complex number implemantation more complete mathematicaly at the expense of backward code compatability and may break some software. Caveat programmer.
Note that there is no attempt to change oddities of Smalltalk syntax. E.g. (3 + 1/2i) --> (0 - 2i) NOT (3 + (1/2)i)
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
[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] removeComplex
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] basicComplex
[1] Can be fixed by adding a "formal" method to Complex with selector #< which only compares real numbers (those whose imaginary component is zero).
[2] Will remain unaddressed for backward compatability.
[3] I propose to remove the isNumber method from Complex and add isNumberOrComplex to both Number, Object, and Complex. [Better solutions anyone? Better name (isNumeric)?] This avoids changing a lot of baseline code.
[C] extendedComplex
[2] The sqrt and ln methods will extended to return complex results for negative numbers.
Other changes may be cased by adding guard code for users of methods which did not formerly return complex results.
-KenD [Ken dot Dickey at Whidbey dot Com] ^^^==============unComplex.txt===============^^^