Nicolas, If I'm following you on the matlab matrix exponential business, we should be able to handle such things polymorphically: exp sent to a matrix would do the right thing for a matrix, just as Float and Complex would respond appropriately. The sticking point here is whether operations on floats should produce complex numbers in place of bounds errors; based on the arguments presented over the past few days, I vote no. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier Sent: Thursday, August 13, 2009 6:46 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Igor Stasenko <siguctua@gmail.com>:
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.
Agree, from pragmatic POV, it's better to not break a majority of existing code Complex is unused in base image, and most #sqrt senders wouldn't know how to deal with a damn imaginary result. I have no solution for this simple annoying thing. Installing error handlers to deal with complex extension is quite boring too... Regarding quality of design decisions, Matlab is far from being my top choice (definition of < for complex would be a grief quite related to this thread...), but I note the existence of mexp msin etc... (exp would collect the exponential of each matrix element)... It's good to know we are not the only ones annoyed, so yes, we could tolerate these unsatisfying selector variations. Mathematical expressions are context dependent (idealy notations are defined in preamble). Translated in Smalltalk world, that would mean MethodDictionary would be Context dependent... But I should better stop here, I can feel like a burning smell coming from my neurons. Nicolas _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project