I love these sorts of ridiculous arguments, because the problem is fundamentally a question of design.Do you design accounting for the expectations of reasonable people, or do you design for programmers :)
Seriously, there's a bigger question here than should you or should you not compare fractions and reals. The question is "for whom is Pharo written?" IEEE754 run contrary to all of my 18 years of sudying math and using rational numbers. I expect the semantics 1/10 = 10/100 = 100/1000 = 1/2*1/5 = 0.5 * 0.2 based on math in Q. This is no different from expecting 0.1 + 0.2 = 0.3 and not 0.29999999.... If you're building software intended for ordinary people, programmers who rarely do computational mathematics, and for educational use, then defaulting to arbitrary precision scaled math is the right way to go, as it matches the expectations of the audience. If you're defining the default behavior of numbers in the system, the principle of "thou shall not commit premature optimization" should come into play. If you're that desperately in need of floating point speed, you're also probably capable of applying that and other optimization techniques accordingly, as befits your problem. Consider IEEE754 floats as optimization for a specific class of application, but a de-optimization for all other uses. Now if you're only designing Pharo for people who program IEEE754 float intensive applications, then by all means, go right ahead and make them the default. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
