You're cargo culting. Floating point numbers are perfectly fine for financial modeling and forecasting. If your goal is to figure out what stocks to buy/sell, it doesn't matter if your software calculates the P/E ratio as 19.232738273816 but the actual value is 19.232738273817. It doesn't even matter if you calculate it as 19.23 but the actual value is 19.22.
When you're storing balances or transacting payments between institutions, you need to emulate a specific set of operations, part of which includes using fixed point numbers. It is not sufficient to just use fixed point, you also need the correct number of digits (AFAIK it's 4 digits with US currency) you need the correct rounding mode, etc.
Every few years someone comes along with a big new idea to rewrite the aging dinosaur COBOL code that runs the financial world in something modern. It never works. Nobody wants to go through the old COBOL code to figure out exactly what the code does, they take a greenfield approach with a description of what the UI is and an incomplete spec of the operations that need to happen. And then when it comes time to test the system, they get balances and numbers that are wrong. Because the only thing they know is "we need to use fixed point" but never bother to understand the actual full scope of how basic financial arithmetic is unique, and different from "normal" arithmetic.
The problem gets compounded as you chain more operations together. Financial calculations often involve long sequences of operations and that is where you can see the true effect of what I am mentioning.
With numbers that are large enough, a 1% or 0.1% difference means a lot of money. And if you have an automated system making decisions based on those numbers that can translate into financial ruin, legal problems, etc.
Leave the ad hominem aside, btw, noone wants to hear about it.
Fixed point numbers have finite precision. As soon as you multiply two fixed point numbers you risk losing precision unless you use more space for your result. You can’t fix your “long chain of calculation” by making it fixed point as you’ll still be rounding things (unless it happens that all your numbers need 54-63 bits of precision and you were wasting bits on the exponent)
Apart from in accounting, the two problems with floats are nonassociativity and speed, neither of which are particularly relevant here.
The risk of losing money does not look like subtle floating point rounding errors. It looks like someone fucking up a formula in excel or the model being wrong or the model being right but risk not being hedged.plenty of people in finance will add percentages as x + y instead of doing (1-(1+x)*(1+y)) because it’s simpler (this works fine because log(1+x) is approximately x when it’s small, and it can obviously be made better by taking the log earlier but plenty of percentage inputs to a model may be rough guesses anyway (who cares if you write 5% or log(5%)))
> Nobody wants to go through the old COBOL code to figure out exactly what the code does, they take a greenfield approach with a description of what the UI is and an incomplete spec of the operations that need to happen.
The only way to improve on this description would be to note that the contract rate for each of the persons involved in this endeavor would be in the $485/hour range (of which, the labor provider might get $50). And then to note the 12 layers of management sign-off/approval on top of that - billed separately.
When you're storing balances or transacting payments between institutions, you need to emulate a specific set of operations, part of which includes using fixed point numbers. It is not sufficient to just use fixed point, you also need the correct number of digits (AFAIK it's 4 digits with US currency) you need the correct rounding mode, etc.
Every few years someone comes along with a big new idea to rewrite the aging dinosaur COBOL code that runs the financial world in something modern. It never works. Nobody wants to go through the old COBOL code to figure out exactly what the code does, they take a greenfield approach with a description of what the UI is and an incomplete spec of the operations that need to happen. And then when it comes time to test the system, they get balances and numbers that are wrong. Because the only thing they know is "we need to use fixed point" but never bother to understand the actual full scope of how basic financial arithmetic is unique, and different from "normal" arithmetic.