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