2009/8/18 Stéphane Ducasse <[email protected]>: > > > 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" >>
You can put the Complex under Number inheritance tree only if you give a meaningful answer, what is < and > operator means for complex values. Good luck in attempts to stick wings to pink elephant and pretend that it can fly. >> [2] 1i squared. "-1 + 0i" >> 1i squared sqrt. "ERROR" this can be solved by adding #sqrt method to currently existing Complex: sqrt ^ (self ln /2) exp >> 1i squared real sqrt. "ERROR" square root of negative value is undefined. as well as division by zero undefined. School math. >> >> [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] >> >> +1 to return false for #isNumber method for complex values. It is not a number. And because of that, it can't be compared/ordered using < or > operators. >> 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. >> feel free to add the complexLn / complexSqrt to existing Number methods. I don't see why existing methods should change. >> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
