today I'm thinking about the "don't use floating point for money" advice I hear all the time. It obviously has a lot of truth to it.

But -- Excel/Google Sheets uses floating point for all of its calculations, people use spreadsheets for money calculations all the time, and it generally seems to work just fine -- the results get rounded for display.

So I'm trying to figure out if there's a more nuanced guideline than "never use floating point for money".

thinking about trying to define a "safe zone" and a "danger zone" for floating point. maybe something like:

safe zone:
* all integer values (like 1.0, 234.0) behave 100% exactly the way you'd expect, UNLESS (!!!) they're more than 2^52. You can check for equality, it's fine.
* adding up ~100 numbers and rounding the result to 4 decimal places or so is going to work fine, as long as the numbers are roughly the same size

@b0rk No, don't do that.

64-bit IEEE754 FP give you 15 decimal digits of precision.

That may be 15 for an integer, or 13 before and 2 after decimal separator, or 11 before and 4 after decimal separator.

The point is: you don't get to choose. The data type guarantees you get 15 digits and the decimal point automatically floats back and forth.

@b0rk The money is a different beast.

Someone decided how money values should behave and how many digits after decimal separator are needed and also how they are rounded.

Some standards require rounding up, some down, some also up, down and 5, ...

@b0rk Some goods require more digits after decimal places, eg. goods that are sold in bulk by weight, such as small screws.

@b0rk Sure, you can get very far with floating point, a bunch of tests and fuzzing.

But the FP datatype is a poor fit for the given domain: it will *gladly* calculate numbers that are out of bounds of the domain, which is having more than 15 significant digits.

It will do this *without giving you any warning* it is losing information.

That is poor engineering.