> 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.

In this case, we're comparing a representation which is exact, compared to one which is approximate. The numerical analysis which you are quoting tells you how close (if not exact) your (approximate* representation is. It's irrelevant when compared to exact, because as long as the other benefits you gain (much larger and smaller numbers) aren't needed, that's all downside.

> 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.

You have to do that work with floating point numbers as well, you just also have to make sure there's not error that needs to be rounded. There is not advantage to floats here, but there is one less thing to worry about with integer values.

> repeatedly make untrue claims about FP calculations

I have made no untrue claims that I'm aware, and I haven't noted you pointing out a specific claim as untrue with evidence that I didn't later point out that you were misinterpreting me on. Please feel free to provide evidence though.

> 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.

As noted above, it's irrelevant when compared to a representation with no error of the same type. Please stop inflating my assertions to cover more than they directly claimed. This is a straw man argument, please stop.

> 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.

Care must always be taken with moving between a real currency amount and an interim amount. It makes sense to switch representations at that point, and deal with the amount with a representation that is appropriate for partial values (floating point may be appropriate here). At the point it's stored again, it should be converted to an exact representation again. Partial cents are not valid amounts of currency to have, so it makes sense to deal with the difference before it is represented as a currency again.

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

I'm saying that Excel isn't only interested in representing currency. If they were, they may have chosen a different representation. Since their constraints are that they also need to be able to accurately represent 0.00001, they are going to choose the best hardware supported representation that support all their needs. That ends up being floating point. For a currency, quite a few of those requirements are no longer needed, so a different trade off is possible.

> 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.

That's not all it is. It's decimal floating point, not binary floating point, meaning it can exactly represent all the base 10 values in it's range. That is fundamentally different than binary floating point, and the fact they chose this representation is what "makes it appropriate for financial and monetary calculations" in their words, illustrates my point.