Begin forwarded message:
> From: "Schwab,Wilhelm K" <[email protected]> > Date: August 18, 2009 2:09:15 AM CEDT > To: "Ken.Dickey" <[email protected]> > Cc: Stéphane Ducasse <[email protected]> > 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:[email protected]] > 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===============^^^ _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
