Treating reals as complex (giving them a zero imaginary part) is a bad idea. Reasons include: (1) need float and double for FFI (2) compatibility with other dialects (3) avoid wasting space to hold unneeded imaginary parts Sig is correct to point out that sometimes one wants to do purely real arithmetic with the domains of various functions restricted as appropriate. Complex numbers should be separate from reals. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Thursday, August 13, 2009 6:07 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>:
2009/8/13 Igor Stasenko <siguctua@gmail.com>:
2009/8/13 Â <csrabak@bol.com.br>:
For the mathematical part yes. Now, submiting to all the list, I want to propose a modification in the code based on Smalltalk style (the comments w/"csr" are only for my explanation and should not go to the production code!):
< other "Can only compare with pure real or imaginary parts" ((self imaginary = 0) and: [other imaginary = 0]) ifTrue: [^ self real < other real].              "csr: if it's true you
i think, if imaginary part is zero , then Complex values should be normalized back to real ones (obviously to conserve the memory), and therefore the test 'self imaginary = 0' is redundant.
Hi Igor, this is Behavior of Complex package available in VW. However, I wonder how you can conciliate the previous requirement: -2 asComplex sqrt
For example, I want this function myFun ^x sqrt arcSin But I know -4 myFun will fail...
So, I hear you and write myFun ^x asComplex sqrt arcSin But there, problem, 4 myFun will raise an error, so as 4 asComplex myFun
Then, i can write smelling code like this - that's no real fun ;) myFun ^x asComplex sqrt asComplex arcSin
unless of course you propose I hide this shit behind some other selectors like: myFun ^x complexSqrt complexArcSin
but then I will probably want some other extensions like the quaternionArcSin, the squareMatrixArcSin, etc... so, I don't know if I'm really satisfied with those selectors...
You are right about drawbacks of normalization. I suggested that by taking Ken's implication, that any real number is a complex number with imaginary part = 0. I'm not very satisfied with selectors , like arcSin/complexArcSin too, but is there other way to put two different functions into a single class (Float) - without assigning different selectors to them? I hope you agree with me that arcSin and complexArcSin is two different functions with different behavior , as well as sqrt and complexSqrt. They could be the same (with complex behavior) , if we imply that real numbers is a complex numbers with imaginary part =0. But once we assume that , we automatically losing the set of functions which defined strictly over a real set and which should throw an error(s) if argument is not in valid range. And i'm not in favor of losing that.
Nicolas
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project