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: [email protected] [mailto:[email protected]] On Behalf Of Nicolas Cellier Sent: Thursday, August 13, 2009 6:46 PM To: [email protected] Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Igor Stasenko <[email protected]>: > 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. > 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 [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
