> BigDecimal is also a viable solution, but it's entirely unnecessary and the cost really is enormous especially if you need to handle a large number of transactions. But sure, if you say performance genuinely isn't an issue go with BigDecimal.

That is exactly what we currently do, and speed of computations is definitely not an issue at all. If we have performance related problems (and we do sometimes), they have never in 10 years originated from numerical computation just taking too long, but always from other inefficiencies, quite often of architectural nature that uselessly burn a thousand times more cycles than the numeric part of the job.

BigDecimal provides exactly what we need: a no-brainer, easy-to-use, easy-to-understand and always correct vehicle for the calculation of monetary sums. It lets our developers focus on implementing the business logic, and also on making less of the described high-level failures that get us into actual performance troubles, instead of consuming a lot of mental share just to “get the computation right“ in all circumstances.

I think its generally assumed that the unqualified term "floating point" is generally referring to binary floating point, which is not the same as decimal floating point. You don't want to use binary floating point for representing money. Furthermore fixed-point refers to a decimal value with a fixed number of bits for the integral and fractional parts, which is not the same as previously suggested system with an implicit decimal point (e.g. multiplying by 10^N for N places of decimal precision). real fixed-point math can be a better and more accurate system if you're working within a well defined range. Regardless of the system you're using, there are only 2^N unique values that can be represented in N bits, binary floating point distributes them unevenly across a huge range. If you are representing a smaller range with a fixed-point system, it will necessarily give you better precision.

How on earth is using the wonkiest possible representation a better solution when you need precise results? In this case, even integer overflow would be a better failure mode than being a few cents off - because it would get noticed pretty quickly in comparison.

Hell, floating point isn't even a good way of doing imprecise arithmetic on larger numbers. What you would actually want is log arithmetic, but that's not what the hardware implements (even though it's simpler). It gives you roughly the same overall precision over each range but stops it from suddenly being cut in half as the exponent changes.