@b0rk yes, but...when you're dealing with money, why would you ever choose to use something that has precision errors when you can choose a solution that doesn't?

It seems like good advice regardless of how many bits of precision we have. Equality tests going wonky 20 digits out vs 10 digits out is still a failing test.

@b0rk This is a lovely idea. Re "all integer values,"
there are some corner cases where Float64's interact with generic data structures like maps, and sets because often Float64's equality and comparison do not obey the contract needed by data structures that hash or sort internally.

This can lead to oddities around questions like "does this collection contain this zero"?

For example, The caveat in the docs for the boxing type for Java double explains how Java makes double arithmetic meet user's expectations most of the time while inter-operating with generic collections. Java collections use .equals to compare values, not primitive ==, which means that a set can separately contain positive and negative zero and may contain one but not the other.

Negative zeroes might be rare in practice, but this might affect users who parse floating point numbers from a field pre-populated with a minus sign, like discount: -_____ or, iirc, when using rounding mode towards -Inf.

@b0rk I would never use any float for money - you never know when things will get weird. Just use BigInt if you are in JavaScript / Node.Js. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt

Also if you do need to add more than 100 floats, just do a tree-like summation (add neighbours, then add those results to their neighbours, etc. Minimizes loss.). For extra precision sort first, so you add like to like.

@b0rk Something I'd be curious about is how this works in practice. What are banks using? Governments?

Would you use signed integer amounts of pennies? Mils? What about interest rate calculations, or converting between currencies? Is anyone actually using the special libraries/APIs for dealing with currency? What is the largest number, realistically, anyone has to deal with? One quadrillion? Etc

@b0rk It also comes from before decimal64 and decimal128.

(I don't know why they even bothered with decimal32.)

@b0rk that is about half of what I was going to say; 32bit float used to be really common, because people were afraid (sometimes justified, sometimes not) 64 bit was too resource hungry.

But the other half is guard bits: 20 or more years ago, there were still some cpus that provided floating point without guard bits, and the lack of guard bits causes errors to grow much faster. (This created some problems for some console video games I worked in that era, but fortunately no money involved!)

@b0rk Anecdotally, I've heard that people who do Monte-Carlo style financial projections intentionally ignore that advice. For example, to compute a projected range of returns to describe the risk associated with a financial instrument or proposed asset allocation.

I think the reasoning is that, since hardware acceleration for 754 is substantially better, being able to do a greater number of iterations in the same amount of time contributes more to the accuracy of the results than something like using 854-based decimals would.

@b0rk Another thing that really blows my mind about floats is issues when thinking about them as line vertices.

For example, if you have two lines, one from (0,0) to (1,1) and another from (0,1) to (0.5,0) and you compute "the intersection point between these two lines" you have to remember that the intersection point doesn't actually lie on either line! It will be some position just slightly off due to precision issues.