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