Re: [Pharo-project] Complex neurotic
AFAIK, one has to be careful ordering complex numbers:
I am aware of this.  There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true  1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN
If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer. Â
An answer to what? Â I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD
Perhaps #isNumber should answer false. I would be very careful about advertising an order that might not behave as people expect. The example of -1 asComplex < 1 asComplex is simple enough, but anything that invokes dictionary ordering (or whatever other definition is used) will get tricky with questions of floating point precision. Also, Float has much more in common with Number than would Complex. A float can be approximated by a fraction; a Complex in general cannot. That alone might be justification for treating complex numbers as something different. Take the real or imaginary part or the modulus, and you have a number again. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ken.Dickey Sent: Tuesday, August 11, 2009 9:46 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex neurotic
AFAIK, one has to be careful ordering complex numbers:
I am aware of this.  There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them. What I object to are bad behaviors for things which are perfectly well defined. Currently: -1 asComplex isNumber --> true  1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error -4 sqrt --> error -3 ln -> NaN
If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer.
An answer to what? Â I wrote the test cases first and then did code to make the tests pass. I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number. What would you expect of the following? -1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex. One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail? Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). I much prefer to get an exact 1. Why should I expect complex numbers to be unreasonable? $0.02, -KenD _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/12 Ken.Dickey <Ken.Dickey@whidbey.com>:
AFAIK, one has to be careful ordering complex numbers:
I am aware of this. Â There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them.
What I object to are bad behaviors for things which are perfectly well defined.
Currently:
-1 asComplex isNumber --> true  1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error
-4 sqrt --> error
and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt
-3 ln -> NaN
same as above, use it as: -3 asComplex ln.
If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer.
An answer to what? Â I wrote the test cases first and then did code to make the tests pass.
I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number.
What would you expect of the following?
-1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex.
i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one.
One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail?
Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). Â I much prefer to get an exact 1.
Why should I expect complex numbers to be unreasonable?
They shoudn't, just keep real numbers be reasonable in parallel :)
$0.02, -KenD
_______________________________________________ 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.
Sig, +1+0.000000001i :) The small imaginary part is due to my concern over calling complex numbers "non-scalars." In what sense do you mean that? They are indeed used as a field of scalars for vector spaces. That sticking point aside, they are different, and I agree they would be best treated somewhat separately, so that -1 sqrt is an error, -1 asComplex sqrt gives a complex (pure imaginary) result. Bill -----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 3:16 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex neurotic 2009/8/12 Ken.Dickey <Ken.Dickey@whidbey.com>:
AFAIK, one has to be careful ordering complex numbers:
I am aware of this. Â There are a large number of ways to define #< for complex numbers -- and a large number of problems with each of them.
What I object to are bad behaviors for things which are perfectly well defined.
Currently:
-1 asComplex isNumber --> true  1 asComplex isNumber -> true -1 asComplex < 1 asComplex --> error
-4 sqrt --> error
and it should. Not many people using a complex numbers. And -4 is an integer number, not complex number (i hope this non-objectionable?). And sqrt function is not defined for real/integer numbers < 0 ,and should lead to error, period. If you change this behavior, some of code will fail to work correctly , definitely. But you are free to use something like: -4 asComplex sqrt
-3 ln -> NaN
same as above, use it as: -3 asComplex ln.
If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer.
An answer to what? Â I wrote the test cases first and then did code to make the tests pass.
I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number.
What would you expect of the following?
-1 asFloat < 1 asFloat. -1 asNumber < 1 asNumber. -1 asFraction < 1 asFraction. -1 asComplex < 1 asComplex.
i personally, don't see any reason why bother defining an ordering operator for non-scalar value(s). Complex numbers is not scalars and ordering operator having a little sense on vectors (however you can find its defined in Point protocol). I really wonder, where #<, #> could be used for Point(s), or vectors in general? And there always will be questions how to define them. As for complex numbers, i wonder , what is correct answer in comparison between real number and any complex number (and moreover, what is the mathematical meaning of such comparison?), because if you introducing it, you can expect someone to compare occasionally: (a * x) < (b * x) where a,b,x could be either complex or real numbers, and #* behavior could turn the complex number to real for one side, but not for another one.
One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail?
Smalltalk is known for reasonable behaviors. Â E.g in Java (1/2) + (1/3) + 1/6) can yield zero (integer division truncates). Â I much prefer to get an exact 1.
Why should I expect complex numbers to be unreasonable?
They shoudn't, just keep real numbers be reasonable in parallel :)
$0.02, -KenD
_______________________________________________ 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
Em 11/08/2009 23:45, Ken.Dickey escreveu:
AFAIK, one has to be careful ordering complex numbers:
I am aware of this. There are a large number of ways to define < for complex numbers -- and a large number of problems with each of them.
What I object to are bad behaviors for things which are perfectly well defined.
Currently:
-1 asComplex isNumber --> true 1 asComplex isNumber -> true
Those are well defined.
-1 asComplex < 1 asComplex --> error
This now would only be "well definede" if you make a painstakingly checking that the imaginary part is equal as well. . .
-4 sqrt --> error -3 ln -> NaN
Most applications do not work in Complex but rather in Real (in the sense of 'non imaginary') corpus, so the only way to evade this conundrum would be to have a System wide setting (which I frown at) or a per package (better even if could do in a way to circumscribe to application level), like a Number>>complexResultsAllowed Number>>complexResultsNotAllowed pair, to allow or disallow the results come in Complex or not.
If in doubt, I would #shouldNotImplement #< until we can get a conclusive answer.
An answer to what? I wrote the test cases first and then did code to make the tests pass.
I am certainly open to alternate definitions, but I think if an object answers true to isNumber it should behave as a number.
The problem is that the result to this answer is arbitrary and result of Smalltalk modeling, not a thesis in type theory or Mathematics... The same kind of "countersense" happens today in Matrix. It is located in the Collections-Unordered package, but we have the following: Matrix>>isSequenceable "LIE so that arithmetic on matrices will work. What matters for arithmetic is not that there should be random indexing but that the structure should be stable and independent of the values of the elements. #isSequenceable is simply the wrong question to ask." ^true Depending upon what kind of rigour you want to defend you'l find the comment "funny" or something else ;-).
What would you expect of the following?
-1 asFloat < 1 asFloat.
true
-1 asNumber < 1 asNumber. true -1 asFraction < 1 asFraction. true -1 asComplex < 1 asComplex. an exception.
One can add checks and make off-axis complex numbers fail (why?), but why cause the last case above to fail?
Because even in pure mathematics there is not a ordering for Complex numbers. In problem domain (like certain problems in Electrical Engineering, for example) -1 asComplexSubclass < 1 asComplexSubclass. would return 'false' and -1 asComplexSubclass = 1 asComplexSubclass. could return 'true'.
Smalltalk is known for reasonable behaviors. E.g in Java (1/2) + (1/3) + 1/6) Not missing the oportunity of the pun, this is Complex case to obtain reasonable behaviour :-D
participants (4)
-
csrabak＠bol.com.br -
Igor Stasenko -
Ken.Dickey -
Schwab,Wilhelm K