+1 -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Wednesday, August 12, 2009 9:06 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 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.

returned, so no need the iFalse part" ((self real = 0) and: [other real = 0]) ifTrue: [^self imaginary < other imaginary]. "csr: same here" ArithmeticError new signal: 'Complex numbers are not generally comparable' "csr: Only will happen if no one of the above blocks returned"

But back to the question: in given form, i really don't see what is the meaning of #< operator on Complex numbers? Because , obviously, in first place, i expecting that #< method serves to compare Complex numbers, not mix of real and complex, but implemented in such form, the value of such method is nearly zero (in complex plane ;). So, the question remains the same: is it worth adding it, just for the sake of complete protocol(s)? P.S. diving into complex plane uncovers many potential pitfalls to those who expecting a certain behavior of mathematical functions over a real numbers. In first place square and square root. It is good that with introduction of a complex numbers we can be sure that x sqrt squared = x for any real x. The complex numbers gives us a impression that from now on, the square function and squared root functions is reversable. But they are not for a complex numbers. In practice this means, that one, who using a complex math in his code, should know well the properties of complex numbers, because this is not so trivial as with real numbers & school algebra. And such people, basically don't need the things with questionable or controversial behavior such as #< operators on a complex plane. Then the aim of Complex package developer should be to not introduce more confusion to people who is not using/learnt the complex numbers, and leave attempts to help people who can - because they could care for themselves well.

HTH

Em 12/08/2009 21:39, Ken.Dickey < Ken.Dickey@whidbey.com > escreveu:

OK, here is a strict version. Complex>>< only compares numbers on the real or imaginal axis and throws an "incomparable" error otherwise. The ComplexTest>>textCompare checks obvious cases.

Is this version (more) acceptable?

As usual, please feel free to correct (or send me corrections) for better coding style (e.g a shorter/better error message) as well as any dumbness on my part.

Cheers, -KenD ------------------------Complex < other "Can only compare with pure real or imaginary parts" ((self imaginary = 0) and: [other imaginary = 0]) ifTrue: [^ self real < other real] ifFalse: [((self real = 0) and: [other real = 0]) ifTrue: [^self imaginary < other imaginary] ifFalse: [ArithmeticError new signal: 'Complex numbers are not generally co mparable'.] ] ------------------------

_______________________________________________ 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

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.

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

2009/8/14 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

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

Agree for pragmatic reasons. I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them. To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with polymorphism: f: A -> A f: B -> B Problems arise when f is defined only on a subset A* of A, but has an extension over B: f: A* -> A f: A -> B f: B -> B First two definitions are ambiguous, and expectations will vary with applications. This is the case of #sqrt. Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt. So far so good, and this is in the spirit of Squeak Complex implementation. But Igor added that in case of this property on a subset B* f: B* -> A then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i. I argue that though the two features are appealling, they are hard to mix. That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions... Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though. That's longer, I don't know if clearer... Nicolas

Nicolas, I think you might be reading more than I intended into my mention of polymorphism. It is true that the real-to-complex transition fits as an extension of the domain of a function, but I'm less comfortable doing that with real-to-matrix. The real line is a subset of the complex plane. Real numbers can be treated as linear transformations[*] which makes them a 1x1 matrix. Still, it feels like a stretch to extend that into a higher dimensional space, but I might be missing something. However, my focus was not on mathematics but on the software aspects of the problem: in a C* world, there are only functions, and putting aside C++'s overloading capabilities, the procedural programmer is "forced" to start with a function, and to use a different name for each argument type. So they end up with normReal(x); normMatrix(x); etc. where we can simply do x := Float pi. x norm. x := Matrix vandermonde:5. x norm. and get sensible answers for each via polymorphism. Does that make sense? Of course, sometimes a number is just a number, and they can be pretty useful by themselves. We should not throw them away too easily. I suspect that any package that breaks floating point computation will be summarily ignored. Bill [*] If nothing else, that is the insight behind the Frechet Derivative which rearranges the familiar difference quotient to view the derivative itself as a linear transformation, all the way down to the one-dimensional case. -----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 8:23 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] #< if at first you dont succeed.. 2009/8/14 Schwab,Wilhelm K <bschwab@anest.ufl.edu>:

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

Agree for pragmatic reasons. I was just exploring alternatives implied by this no, and #complexSqrt and the like are one of them. To summarize, you tell me that if a function f is well defined other a whole set A, then you encourage it's extension to a superset B with polymorphism: f: A -> A f: B -> B Problems arise when f is defined only on a subset A* of A, but has an extension over B: f: A* -> A f: A -> B f: B -> B First two definitions are ambiguous, and expectations will vary with applications. This is the case of #sqrt. Igor said, very simple, just forget definition #2, keep #1 and #3 and write -2 asComplex sqrt. So far so good, and this is in the spirit of Squeak Complex implementation. But Igor added that in case of this property on a subset B* f: B* -> A then it would be better to automatically classify result as member of A for any element of B* Answer a Float rather than carrying a Complex with null imaginary part for example like 4 asComplex sqrt -> 2 rather than 2+0i. I argue that though the two features are appealling, they are hard to mix. That's the point that we were discussing, leading us to an ugly solution like FORTRAN non generic INTRINSIC functions... Concerning Matlab exp/mexp, ambiguity is between 1-D array (Array Programming Language/FloatArray like extension) and square matrix (infinite series expansion). That's a bit different, and the example was not that well chosen, I confess. Smalltalk implementations are potentially exposed to the same ambiguity though. That's longer, I don't know if clearer... Nicolas _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project