91–100 of 120 posts
Earlier quoted context omitted.
the axiomatization of floating point arithmetic is much larger than the axiomatization of real arithmetic, so it is reasonable to describe the former as more complicated.
Complexity of the definition isn’t particularly interesting, the properties of the object being defined can be. The reals are stranger than most people realize.
Ages ago, when I was in college, a "numerical methods" course was more or less obligatory... has that changed? Anyway, toying with a slide rule is a fun way of making these things very obvious, because you are essentially working with something like 3-digit floating point. When you find yourself subtracting 1.234 from 1.235, but you know that both the "4" and the "5" are really fuzzy around the edges, it becomes obvi…
I do somewhat wonder if numerical methods have suffered from their success; like everybody uses LAPACK via Numpy but understanding it under the hood, that job always belongs to the next department over wherever you are, haha.
Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact. My current approach is that I try to guess (or ask) how a customer understands or checks a statement/invoice. The customer usually takes a calculator and enters the rounded numbers they see. I then try to do all programmatic calculations exactly the same way: Operation - round - operati…
I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague. > The system can be too exact Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?
this will typically get transmuted through multiple layers of javascript, xml, back end java, cobol, SQL, python, some domain specific language, and back again.
i think it is our educational system that is weird. we teach students from arithmetic to differential equations assuming they are working with Real Numbers and never really talking about what that means or what a Field is. Then we present computation as something that can easily be done with Real numbers. Which is a lie because we don't even know if Pi plus E is rational or not. Then we present computers as tools of…
I do remember being taught the difference between rationals and irrationals in high school.
Another aside... The really crazy difference is between the definable and non definable numbers. The first which includes everything from pi to every busy beaver number is countably finite just like the integers, only the nondefinables (numbers whose shortest mathematical definition would not be finite or not exist) give the reals their uncountably infinite nature
Earlier quoted context omitted.
Complexity of the definition isn’t particularly interesting, the properties of the object being defined can be. The reals are stranger than most people realize.
What's a strange thing about reals?
I decided years ago that the next time I hear someone suggesting we use floats / doubles to represent money amounts, I am going to punch them in the face.
Re money systems: I have found that problems arise no matter whether floats are used or something else: The system can be too exact. My current approach is that I try to guess (or ask) how a customer understands or checks a statement/invoice. The customer usually takes a calculator and enters the rounded numbers they see. I then try to do all programmatic calculations exactly the same way: Operation - round - operati…
I thought "money systems" always worked in whole units of some fraction of your currency, e.g. "millicents" or similar, and shunned floating point arithmetic like the plague. > The system can be too exact Indeed, high precision, low accuracy! Fixed-point arithmetic can be both precise and accurate if everyone agrees on the same system. Maybe we don't, and that's the problem?
IEEE has had these Decimal types for a while, but IBM is the only company shipping CPUs with them.
Fixed decimal is still used where appropriate, but Decimal floating point is a critical feature for some processes.
While personal taxes typically drop the cents, tariffs and other taxes are often small percentages as an example.
There are software implementations if you don't need performance.
But Decimal64 has a lot more represented values and it is easier to trap on some edge cases.
As Decimal floating point types were added into C23 we will see if hardware support follows.
Note this is also why HP calculators were more accurate for a given bit size, because the engineering ones used radix 10 floats.
It’s not so much that floats are weird, but that they are not reals. Most of the problems happen due to confusion about this fact. Reals are much weirder/more interesting than floats, imo.
the axiomatization of floating point arithmetic is much larger than the axiomatization of real arithmetic, so it is reasonable to describe the former as more complicated.
Earlier quoted context omitted.
the axiomatization of floating point arithmetic is much larger than the axiomatization of real arithmetic, so it is reasonable to describe the former as more complicated.
yeah i have never really seen someone breakdown the axioms of floating point mathematics, like how do you define addition in a system that is not closed under "normal" addition.
Another example: compare the two algorithms, that are actually pure-mathematically equal:
def fc(x):
return sqrt(x+1) - sqrt(x)
def fd(x):
return 1/(sqrt(x+1) + sqrt(x))
xs = np.linspace(10\*14,10\*16,10000)
plt.figure(figsize=(8, 6), dpi=120)
plt.plot(xs,[fc(x) for x in xs])
plt.plot(xs,[fd(x) for x in xs])