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: [email protected] [mailto:[email protected]] On Behalf Of Ken Dickey Sent: Saturday, August 29, 2009 11:08 AM To: [email protected] 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
