3 ms·

>>> 0.2 + 0.1 > 0.3 True That is false. What is it that is "...is much harder to demonstrate in other languages? I am missing something

by worik 1y ago

deleted 1y ago
[deleted]
Jtsummers 1y ago
> That is false. What's false about it? That is the result if you're using IEEE floating point arithmetic.
- tialaramex 1y ago
  It's the result if your programming language thinks 0.2 + 0.1 means you want specifically the 64-bit IEEE floating point binary arithmetic. But, where did we say that's what we want? As we've seen it's not the default in many languages and it isn't mandatory in Python, it's a choice, and the usual argument for that choice would be "it's fast" except, Python is slow, so what gives ?
  - deleted 1y ago
    [deleted]
  - deleted 1y ago
    [deleted]
  - Jtsummers 1y ago
    You aren't answering my question. I asked worik why they're claiming that something that happens is false. It's insane to claim that reality isn't reality. Run that in a Python REPL and that is the result you get.
  - leephillips 1y ago
    Interesting observation about Python providing the worst of all possible worlds: unintuitive arithmetic without any of its speed advantages. But in answer to “where did we say that's what we want?” I would say, as soon as we wrote the expression, because we read a book about how the language works before we tried to use it. Αfter, for example reading a book¹ about Julia, we know that 0.1 + 0.2 will give us something slightly larger than 0.3, and we also know that we can type 1//10 + 2//10 to get 3//10. [1] https://lee-phillips.org/amazonJuliaBookRanks/ https://lee-phillips.org/amazonJuliaBookRanks/
    - tialaramex 1y ago
      > I would say, as soon as we wrote the expression, because we read a book about how the language works I'm comfortable with that rationale in proportion to how much I believe the programmer read such a book. I haven't taken the course we teach say, Chemists, I should maybe go audit that, but I would not be surprised if either it never explains this, or the explanation is very hand-wavy, something about it not being exact, maybe invoking old fashioned digital calculators. The amusing thing is when you try to explain this sort of thing with a calculator, and you try a modern calculator, it is much more effective at this than you expected or remember from a 1980s Casio. The calculator in your modern say, Android phone, knows all the stuff you were shown in school, it isn't doing IEEE floating point arithmetic because that's only faster and you're a human using a calculator so "faster" in computer terms isn't important and it has prioritized being correct instead so that pedants stop filing bugs.
    - zahlman 1y ago
      > unintuitive arithmetic without any of its speed advantages. Using floating-point in Python is still much faster than using an exact type in Python. $ # At this scale, we need to be aware of and account for the timing overhead $ python -m timeit 'pass' 50000000 loops, best of 5: 8.18 nsec per loop $ # The variable assignment defeats constant folding in the very primitive optimizer $ python -m timeit --setup 'x = 0.1; y = 0.2' 'x + y' 10000000 loops, best of 5: 21.2 nsec per loop $ python -m timeit --setup 'from decimal import Decimal as d; x = d("0.1"); y = d("0.2")' 'x + y' 5000000 loops, best of 5: 62.9 nsec per loop $ python -m timeit --setup 'from fractions import Fraction as f; x = f(1, 10); y = f(2, 10)' 'x + y' 500000 loops, best of 5: 755 nsec per loop
- worik 1y ago
  > What's false about it? Mathematics. IEEE floating point arithmetic gets it wrong! Another example of why we should use integer algorithms where ever possible.
librasteve 1y ago
lol, here it is in the https://raku.org https://raku.org repl… Welcome to Rakudo™ v2025.06.1. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2025.06. To exit type 'exit' or '^D' [0] > 0.1 + 0.2 > 0.3 False

>>> 0.2 + 0.1 > 0.3 True That is false. What is it that is "...is much harder to demonstrate in other languages? I am missing something

by worik 1y ago

>>> 0.2 + 0.1 > 0.3 True That is false. What is it that is "...is much harder to demonstrate in other languages? I am missing something

deleted 1y ago

[deleted]

Jtsummers 1y ago

> That is false. What's false about it? That is the result if you're using IEEE floating point arithmetic.

tialaramex 1y ago
It's the result if your programming language thinks 0.2 + 0.1 means you want specifically the 64-bit IEEE floating point binary arithmetic. But, where did we say that's what we want? As we've seen it's not the default in many languages and it isn't mandatory in Python, it's a choice, and the usual argument for that choice would be "it's fast" except, Python is slow, so what gives ?
- deleted 1y ago
  [deleted]
- deleted 1y ago
  [deleted]
- Jtsummers 1y ago
  You aren't answering my question. I asked worik why they're claiming that something that happens is false. It's insane to claim that reality isn't reality. Run that in a Python REPL and that is the result you get.
- leephillips 1y ago
  Interesting observation about Python providing the worst of all possible worlds: unintuitive arithmetic without any of its speed advantages. But in answer to “where did we say that's what we want?” I would say, as soon as we wrote the expression, because we read a book about how the language works before we tried to use it. Αfter, for example reading a book¹ about Julia, we know that 0.1 + 0.2 will give us something slightly larger than 0.3, and we also know that we can type 1//10 + 2//10 to get 3//10. [1] https://lee-phillips.org/amazonJuliaBookRanks/ https://lee-phillips.org/amazonJuliaBookRanks/
  - tialaramex 1y ago
    > I would say, as soon as we wrote the expression, because we read a book about how the language works I'm comfortable with that rationale in proportion to how much I believe the programmer read such a book. I haven't taken the course we teach say, Chemists, I should maybe go audit that, but I would not be surprised if either it never explains this, or the explanation is very hand-wavy, something about it not being exact, maybe invoking old fashioned digital calculators. The amusing thing is when you try to explain this sort of thing with a calculator, and you try a modern calculator, it is much more effective at this than you expected or remember from a 1980s Casio. The calculator in your modern say, Android phone, knows all the stuff you were shown in school, it isn't doing IEEE floating point arithmetic because that's only faster and you're a human using a calculator so "faster" in computer terms isn't important and it has prioritized being correct instead so that pedants stop filing bugs.
  - zahlman 1y ago
    > unintuitive arithmetic without any of its speed advantages. Using floating-point in Python is still much faster than using an exact type in Python. $ # At this scale, we need to be aware of and account for the timing overhead $ python -m timeit 'pass' 50000000 loops, best of 5: 8.18 nsec per loop $ # The variable assignment defeats constant folding in the very primitive optimizer $ python -m timeit --setup 'x = 0.1; y = 0.2' 'x + y' 10000000 loops, best of 5: 21.2 nsec per loop $ python -m timeit --setup 'from decimal import Decimal as d; x = d("0.1"); y = d("0.2")' 'x + y' 5000000 loops, best of 5: 62.9 nsec per loop $ python -m timeit --setup 'from fractions import Fraction as f; x = f(1, 10); y = f(2, 10)' 'x + y' 500000 loops, best of 5: 755 nsec per loop
worik 1y ago
> What's false about it? Mathematics. IEEE floating point arithmetic gets it wrong! Another example of why we should use integer algorithms where ever possible.

librasteve 1y ago

lol, here it is in the https://raku.org https://raku.org repl… Welcome to Rakudo™ v2025.06.1. Implementing the Raku® Programming Language v6.d. Built on MoarVM version 2025.06. To exit type 'exit' or '^D' [0] > 0.1 + 0.2 > 0.3 False