Quote from: realnowhereman on June 09, 2011, 09:39:20 AM

If it's true though, why bother using floats at all?

I have no problem with requiring new code to be fixed point. I am simply pointing out that removing existing floating point code isn't an emergency, that floating point arithmetic is exact when integers having less bits than the mantissa are involved, that panic over imagined precision or rounding issues when using floats for financial software is overblown, and that several Very High Level Languages popular for financial and actuarial work use floats internally, as does COBOL when performance is maximized.

People seem to have the idea that all float operations involve some sort of random fuzziness which causes monetary calculations to drift from their actual values the more floating operations are performed. In reality, floats represent exact values on the real number line, and the result of a floating operation is the nearest machine number to the value that would have resulted had the operation been performed to infinite precision if one exists, and a value systematically chosen with zero bias if the exact value lies halfway between two machine numbers.

So floating operations which yield machine numbers are as exact as integer operations. Since double floats are big enough to represent all Bitcoin amounts, discussion of whether or not to ban floating arithmetic in the source code of the default client is a philosophical one, and not one related to an actual danger the code will "break, or that Bitcoin amounts will become imprecise, if this is not done.

Comments like "such and such a company burns coders at the stake if they use floating point in financial apps," while interesting, make points orthogonal to the points I am making.