Isn't it an expected behaviour (at least for programmers) because of IEEE 754?<p>For example, in Racket this also gives 2.0, but if you are using exact numbers (#e), then it gives exact and correct answer 1.0.<p>Same for Java (and any other language): if you are using Float/Double numbers, then you are loosing precision. Use BigDecimal (or something similar for other languages) if you want exact calculations.
Kind confused what the point is. Is this a complaint that most languages use IEEE 754 for non-integer numbers and he thinks they shouldn't, or a veiled dig about how many programmers don't know this, or...?<p>The color coding of results suggests the author thinks that 2 is wrong and 1 is right, but he's going out of his way to specify floating point numbers, and when subtracting those two floating point numbers the correct answer is 1 and NOT 2.<p>Eg, Ruby thinks 9999999999999999.0 - 9999999999999998.0 = 2, but 9999999999999999 - 9999999999999998 = 1. Which is...correct. Right? Unless you don't think IEE 754 should be the default?<p>I feel like the author is trying to make a clever point, but if so, I'm not getting it.
Note that the Common Lisp example could be abbreviated to:<p>(- 9999999999999999.0l0 9999999999999998.0l0)<p>However, this will only work (either way) in Lisps where long floats are arbitrary precision, like CLISP. In most Lisps (e.g. SBCL, CCL), long floats are just double floats.
For java:
BigDecimal b1 = new BigDecimal("9999999999999999.0");<p><pre><code> BigDecimal b2 = new BigDecimal("9999999999999998.0");
System.out.println(b1.subtract(b2));</code></pre>
prints 1.0
SymPy, being Python, gets it wrong... but if you use S = sympify to transform the long numbers into SymPy objects it works:<p><pre><code> S('9999999999999999.0') - S('9999999999999998.0')
1.0</code></pre>