4 ms·

Well to be fair it is only a wat if you don't know about floating point imprecision. Because that is exactly what is causing this contrary to what is stated. Al

by khulat 11y ago

Well to be fair it is only a wat if you don't know about floating point imprecision. Because that is exactly what is causing this contrary to what is stated. Also python just gets this behavior from C, so the other claim that this is a special case of python is also not true. Since the 1 is shifted 53 bits to the left the number is right at the start of the number range where only even numbers can be represented. You get 900719925470993 as the decimal number which you cast to float : 900719925470992.0 Then you add 1.0 and get 900719925470992.0 because of floating point imprecision and rounding. The next floating point number would be 900719925470994.0. 92 is less than 93 and this gets you this seemingly weird x+1.0 < x = true.

Veedrac 11y ago
It's still unfortunate that `x + 1.0` rounds incorrectly. Python is one of the few languages that has correct (infinite-precision) float-int comparisons, so it's reasonable to expect addition to work similarly. That said, I'm not aware of a language that does better, and I'm aware of many that do much worse.
- renox 11y ago
  There is Frink (http://futureboy.us/frinkdocs/ http://futureboy.us/frinkdocs/) which has interval arithmetic which seems so much more sane than floating point numbers..
  - deleted 11y ago
    [deleted]
  - Veedrac 11y ago
    I looked at Frink a little; it doesn't seem to implement integer-floating addition properly either. 9999999999999999999002 + 49.0 rounds to 9.9999999999999999990e+21, whereas the lesser value 9999999999999999999000 + 50.0 rounds to 9.9999999999999999991e+21. Plus, I'm not a fan of computing with decimal arithmetic, since it's less stable. For instance, min(a, b) <= (a + b) / 2 <= max(a, b) doesn't always hold for decimal floats, whereas it does for (non-overflowing) binary floats. Decimals are generally more prone to this kind of inaccuracy, since they lose more bits when the exponent changes. (Consider a = 1.00000000000000000001, b = 1.00000000000000000003.) Interval arithmetic support is cool, but not useful without effort - bounds like to grow. Plus, Python has bindings for them anyway ;).

by khulat 11y ago

Veedrac 11y ago

It's still unfortunate that `x + 1.0` rounds incorrectly. Python is one of the few languages that has correct (infinite-precision) float-int comparisons, so it's reasonable to expect addition to work similarly. That said, I'm not aware of a language that does better, and I'm aware of many that do much worse.

renox 11y ago
There is Frink (http://futureboy.us/frinkdocs/ http://futureboy.us/frinkdocs/) which has interval arithmetic which seems so much more sane than floating point numbers..
- deleted 11y ago
  [deleted]
- Veedrac 11y ago
  I looked at Frink a little; it doesn't seem to implement integer-floating addition properly either. 9999999999999999999002 + 49.0 rounds to 9.9999999999999999990e+21, whereas the lesser value 9999999999999999999000 + 50.0 rounds to 9.9999999999999999991e+21. Plus, I'm not a fan of computing with decimal arithmetic, since it's less stable. For instance, min(a, b) <= (a + b) / 2 <= max(a, b) doesn't always hold for decimal floats, whereas it does for (non-overflowing) binary floats. Decimals are generally more prone to this kind of inaccuracy, since they lose more bits when the exponent changes. (Consider a = 1.00000000000000000001, b = 1.00000000000000000003.) Interval arithmetic support is cool, but not useful without effort - bounds like to grow. Plus, Python has bindings for them anyway ;).