Fwd: REPOST: Complex Solution Outline

> From: "Schwab,Wilhelm K" <[hidden email]>
> Date: August 18, 2009 2:09:15 AM CEDT
> To: "Ken.Dickey" <[hidden email]>
> Cc: Stéphane Ducasse <[hidden email]>
> 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:[hidden email]]
> 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===============^^^

>
>
> Begin forwarded message:
>
>> From: "Schwab,Wilhelm K" <[hidden email]>
>> Date: August 18, 2009 2:09:15 AM CEDT
>> To: "Ken.Dickey" <[hidden email]>
>> Cc: Stéphane Ducasse <[hidden email]>
>> 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:[hidden email]]
>> 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"
>>

>>
>> [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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>