On: Calc.exe is now open source; there’s surprising depth in its ancient code (2019)

[mtreis86]

Floating point implementations vary among programming languages. On the same machine and OS (win10), the equation 0.3 - 0.1 equals varying numbers depending on the calculator;

Powershell says 0.2,

calc.exe app and libreoffice calc agree with 0.2,

BC running in CYGWin also 0.2,

Python 2 and 3 answer 0.19999999999999998,

JS in Vivaldi and firefox also answer 0.19999999999999998,

But Portacle (Common Lisp) returns 0.20000002

[qsort → mtreis86]

Not sure how this is related, but:

- if you get 0.2, the code is using rational numbers or a custom implementation

- 0.199999...8 is the double precision IEEE subtraction.

- 0.200000...2 is the single precision IEEE subtraction.

This looks like a typecasting/coercion issue. You can likely get all of the above in C++ or Java by using different explicit casts.

[dragonwriter → qsort]

> if you get 0.2, the code is using rational numbers or a custom implementation

IIRC, there are languages that use IEEE double precision but the way they handle default display presents this as 0.2 (basically, they use a display algorithm that displays the shortest decimal expression that has the same double precision representation.)

[vips7L → qsort]

Using doubles in Java you get 0.199999..8, using BigDecimal you get the correct 0.2.

    jshell> new BigDecimal("0.3").subtract(new BigDecimal("0.1"))
    $8 ==> 0.2

[qsort → vips7L]

Yeah, and using float literals you get 0.20000...2:

   jshell> .3f-.1f
   $1 ==> 0.20000002

We got ourselves a hat trick :)

[CraigJPerry → qsort]

0.2 could just be base 10 / decimal floating point rather than the base 2 single/double i think, It’s all ieee754 it’s just the base10 stuff came later

[zokier → mtreis86]

    In [1]: from decimal import Decimal as D

    In [2]: D('0.3') - D('0.2')
    Out[2]: Decimal('0.1')

[raiph → mtreis86]

And then there are PLs that adopt the incredibly radical technique of treating 0.2 as two tenths[1].

[1] https://medium.com/@raiph_mellor/fixed-point-is-still-an-app...

[GrumpySloth → mtreis86]

As far as I know, BC doesn't do floating point arithmetic. It does fixed point arithmetic, built on top of arbitrary-precision integer arithmetic. Which is why it won't give you one of those funny floating point answers. It's what a human would do on a piece of paper.

Floating point implementations can vary not only between languages, but also between different CPUs, if the language relies on the hardware implementation (which is the smart thing to do in most cases).

As a side note: Python's implementation of FP isn't standard-compliant. E.g. when you divide by 5.0 by 0.0, the standard says you should get a +inf. In Python you get an exception.

[adrian_b → GrumpySloth]

Actually, according to the standard, you should get either +inf or an exception. Both behaviors are valid. Nevertheless, according to the standard, the user should be able to choose between getting +inf and getting an exception. If in Python there is no way to mask the divide by zero exception, then that is not standard-compliant.