> This isn't about numerical analysis, which is what you seem to not be getting.

Of course it is. The point of the computation is to get the correct result. Numerical analysis hints at whether your computation will give you the right answer or not.

You're asserting that it's trivial to make sure that your fixnums won't overflow, but in most normal cases where you'll fit into a 64-bit int range, you'll also fit into the 52-bit precision range in a double. If you can prove that ints are OK, then you can just as easily prove that doubles are safe to use.

And unlike floating point rounding errors, where the answers often have some hint about the correct result, undetected overflows silently give you a totally garbage result.

Your system does not magically become 'safe by design' simply because you use ints everywhere, you still need to put in the extra work to make sure your numeric range is always sufficient—at which point you're doing numerical analysis, whether you choose to call it that or not.

Honestly, I'm surprised that you will denounce the usage of floating point numbers, repeatedly make untrue claims about FP calculations, then wave off the entire subbranch of CS that studies how numbers are represented on computers and how those calculations can go wrong as being entirely irrelevant.

> It only takes a single error that causes a value to be less than the correct value by a very small amount and then if there's any place where it exits the system without rounding, that error may be increased to a full minimum difference of the medium ($0.01 in this case).

What? The only case where a number rounds wrongly is when the final value is more than half a cent away from the correct value.

If you can't be bothered to understand how FP calculation works, at least please stop making demonstrably false claims and misleading others.

> By nature of the actual thing being represented by a the floating point value.

As soon as you actually do any
'complicated' math (take a square root or a log), your result is no longer exactly representable, because your results aren't decimals or even rationals, but irrationals.

Even an arbitrary precision number type doesn't help you here—your only solution is an arbitrary precision math package—but that isn't what you're suggesting

It sounds like you think using fixnums everywhere guarantees you the Platonic exact answer, but they can't actually do that:

- If you're doing anything complicated, you will unavoidably be making approximations and rounding. Adding a bunch of extra casts back to fixnums don't allow you to avoid approximation, just a false sense of security.

- OTOH, if you're not doing anything complicated, just totaling small numbers multiplied by round constants, then doubles are provably sufficient at getting an exact answer after rounding.

> When you use excel, you aren't using floats, you're using an excel numeric type which is implemented underneath using floats and some very specific behavior. The fact that it automatically deals with floating point errors and rounding is what makes it not a float.

You're contradicting yourself here. All Excel does is 1) compute using floats (doubles) everywhere and 2) round the result before showing it.

That's exactly what I'm advocating. Whether you choose to wrap it into a special Numeric or Money class doesn't change your answer.

Look, here's C#'s decimal class:
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Must use some fancy arbitrary precision arithmetic right? No, it's just a floating point number—just a particularly wide (128-bit) type.