Just briefly... I'd keep the base numbers simple while leaving the door open for optional, loadable packages to extend comparisons as necessary. IMO, matching the capabilities of C (integers, floating point) plus fractions should be sufficient for a base system. If not, there is the risk of creeping featurism. Not long ago, Ralph Johnson pointed out to a 1998 presentation by Guy L Steele regarding the design of the Java language, and GLS makes good points regarding the need to prevent the definition of a "language" or its "default shipping offer" from offering more than necessary. My 2 cents... Andres. Igor Stasenko wrote:
2009/8/13 <csrabak@bol.com.br>:
Em 12/08/2009 19:30, Igor Stasenko < siguctua@gmail.com > escreveu:
2009/8/12 Ken.Dickey :
"Schwab,Wilhelm K"
Floating point is not always what it seems.
Hence my comment that IEEE floats get "the wrong answer fast". I have used interval math, continued fractions, and linear fractional transforms (a.k.a. exact reals). I agree that each representation has its challenges.
Let's talk for a second about integers.
0 = (0+0i) --> true 1 = (1+0i) --> true 0 < 1 --> true (0+0i) < (1+0i) --> ?? which answer here gives me the least surprise ??
To put it another way
(A = a) --> true (B = b) --> true (A < B) --> true (a < b) --> ?? what do you expect to see here ??
Let me extend your test a little
i do expect that, if :
a < b
and
0 < x
then
a*x < b*x
Your "counter example" is mathematically flawed even in Real (non imaginary):
let a = 1; b = 2 and x = -1:
do you intentionally missed the condition 0 < x?
a < b and a*x > b*x
So there isn't this kind of transitivity for inequality operators at all.
[snipped]
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project