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