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: [email protected] [mailto:[email protected]] On Behalf Of Igor Stasenko Sent: Thursday, August 13, 2009 6:07 PM To: [email protected] Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Nicolas Cellier <[email protected]>: > 2009/8/13 Igor Stasenko <[email protected]>: >> 2009/8/13 <[email protected]>: >>> 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 > [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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
