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
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
