5 ms·

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

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 6y ago
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 6y ago
  > 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.)
- CraigJPerry 6y ago
  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
- vips7L 6y ago
  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 6y ago
    Yeah, and using float literals you get 0.20000...2: jshell> .3f-.1f $1 ==> 0.20000002 We got ourselves a hat trick :)
yakubin 6y ago
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 6y ago
  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.
zokier 6y ago
In [1]: from decimal import Decimal as D In [2]: D('0.3') - D('0.2') Out[2]: Decimal('0.1')
- deleted 6y ago
  [deleted]
raiph 6y ago
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-approximation-727c6facdbff https://medium.com/@raiph_mellor/fixed-point-is-still-an-app...

qsort 6y ago

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 6y ago
> 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.)
CraigJPerry 6y ago
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
vips7L 6y ago
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 6y ago
  Yeah, and using float literals you get 0.20000...2: jshell> .3f-.1f $1 ==> 0.20000002 We got ourselves a hat trick :)

yakubin 6y ago

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 6y ago
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.

zokier 6y ago

In [1]: from decimal import Decimal as D In [2]: D('0.3') - D('0.2') Out[2]: Decimal('0.1')

deleted 6y ago
[deleted]

raiph 6y ago

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-approximation-727c6facdbff https://medium.com/@raiph_mellor/fixed-point-is-still-an-app...