4 ms·

Interesting observation about Python providing the worst of all possible worlds: unintuitive arithmetic without any of its speed advantages. But in answer to “

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

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