Edited the post to add a "floating point isn’t bad or random" section because I really did not want people to take away "floating point is bad". Floating point is amazing! It's just solving an inherently very hard problem.

Follow

@b0rk Maybe it's useful to mention what that problem is? The way I phrase it is that FP is intended for computations where you care about relative accuracy.

@robryk @b0rk My take is that floating point is for when you want to do non-integer arithmetic fast, without using much memory, and you're willing to trade off some accuracy to do that. And that it used to be necessary for many everyday computations when computers were much slower and had kilobytes of RAM, but these days should really only be used for special purposes like 3D graphics and neural net simulations where performance is still critical.

@mathew @b0rk

I disagree that this is the only case.

If (a) you actually care about relative precision of results (b) you can structure the whole computation in the middle so that it's well behaved (i.e. derivative of the logresult wrt logvalue for any intermediate value is bounded by a reasonably small constant) then floating point is actually doing precisely what you want. Fixed point would _not_ be doing what you want then, because it would have fixed absolute precision (so would have worse precision when the output values are small).

This is not as contrived a setup as it sounds like. Many physical processes can be described as such computations (because all intermediate values are noisy, so the process becomes chaotic if it's not well-behaved as described above). This is also how people do computations by hand (e.g. compute everything to some number of significant digits), so it's a model that's very familiar to many.

@robryk @b0rk I wouldn't suggest fixed point as the alternative, except for things like currencies perhaps. I would suggest variable size decimal floats and doing the computation the way people expect.

@mathew @b0rk

What do you mean by variable size floats? Which size varies and what controls how it varies (e.g. what is the size of a result of an arithmetic operation)?

@mathew @b0rk

Do you mean arbitrary precision rationals or arbitrary precision values that are rationals with a power of 2 in denominator? Note that latter (the ones that are called `mpf` in gmp) can _not_ represent e.g. 1/3.

@robryk @b0rk I was thinking arbitrary precision decimal floating point numbers, but it’s nice if languages also have support for fractions so they can compute with 1/3 accurately, yes.

@mathew @b0rk

Arbitrary precision decimal or binary floating point either:
- requires you to actually specify the precision (so is "normal" FP, just wider), or
- doesn't support division (because results of division cannot be made exact at any precision).

@robryk @b0rk Yes. But with arbitrary precision BCD you can specify the precision in base 10 decimals, and the calculation is carried out in base 10, so the effect of precision limits is much easier to understand. Plus you’re not limited to whatever precision your binary (hardware) floats give you.

@mathew @robryk @b0rk There are libraries for doing math in exact rational numbers. Even when this is possible mathematically it usually blows up memory-wise and is intractable even for small toy problems.

@mathew @robryk @b0rk floating point is the workhorse of all scientific and engineering computing. And for good reason; it didn't come out of nowhere, but is the fruit of several decades of figuring out how to do numerical computing using machines.

@jannem @robryk @b0rk Yep. Specialized fields where speed is important still use floating point, and have worked out how to deal with its eccentricities.

@mathew @jannem @b0rk

I don't see any alternative. When I do computations on paper that involve values measured with some uncertainty, I essentially use base 10 floating point.

_If you're in the right situation_ those eccentricities do not matter. It doesn't matter to me that I can't represent exactly 2/3 in decimal floating point -- the value I'm going to e.g. multiply that 2/3 with in a few moments anyway comes from a measurement with some relative error, so I can just choose appropriately accurate representation of 2/3.

@robryk @jannem @b0rk Support for fractions is also woefully lacking from most programming languages.

Ruby is one of the examples that has them:
irb(main):006:0> 4/5r * 2/3r
=> (8/15)

@mathew @robryk @b0rk Not very specialized though. It probably includes the majority of all computing happening in the world. Take games for instance; many games are, at heart, just science or engineering simulators with a beautiful interface.

But games show how to move forward: those simulators are called "physics engines" or "spatial sound libraries" and most game creators don't roll their own. Similarly you should use a numerical library whenever possible rather than do it yourself.

@jannem @robryk @b0rk The game programming that requires floating point is a highly specialized area, handled by a few programmers. As you say, everyone else just uses the engines they build.

Numerical libraries are the same deal. A very specialized area few programmers are involved in.

Most programming isn’t in areas like that where floating point is necessary.

@mathew @robryk @b0rk You're using libraries for the heavy lifting. You still need to do stuff with the data. A library helps you calculate sines or integrate an ODE; it won't use the result for you. You still need to understand what you're doing.

@mathew @robryk @b0rk When you work with sensor readings, measurements, etc. inaccuracy is inherent and unavoidable and FP math is appropriate. It's not just a weird performance trick.

@JuergenStrobel @mathew @b0rk

Note that FP is a suboptimal choice for things where you have predominantly absolute inaccuracy (e.g. time-since-epoch). It shines when your inaccuracy is predominantly relative. That is a usually a good assumption if your measurements are done using a measure appropriate for the scale you're measuring.

@robryk @JuergenStrobel @b0rk True, but I still think it's time we routinely did floating point calculations in decimal, rather than binary, to reduce the number of surprises. Apparently this is finally moving towards being a mainstream opinion these days, because IEEE 754-2008 is a thing.
en.wikipedia.org/wiki/Decimal_

@mathew @JuergenStrobel @b0rk

That doesn't avoid most of the surprises:
- adding lots of small values is still tricky,
- still ~nothing is associative,
- still 1.0/3.0 + 1.0/3.0 + 1.0/3.0 != 1.0,
...

The only one it seems to avoid is that numbers entered as decimal fractions are represented precisely. However, that is, arguably, harmful: it makes it less apparent than other numbers are not, and encourages doing things in a way that relies on some outputs being exact.

@robryk @JuergenStrobel @b0rk Right, which is why I think floating point should be avoided as much as possible, and when you have to do it, you should try to use decimal floats, and ideally not ones with fixed precision.

If I were designing a programming language I'd call the data type "approximate" rather than "float", to act as a red flag to programmers.

@mathew @robryk @b0rk There's no way to do automatic variable precision FP, it would devolve to rationals and is intractable in general. Also decimal FP is less dense, accurate and performant than binary. Many scientists and other users will prefer speed and accuracy over being able to present 1/10 exactly, especially in the common case where they don't see any numbers at all.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.