MS Excel uses floating point, and it's used a ton in finance. Don't use floating-point for monetary amounts if you don't know what rounding mode you've set.
Integer cents implies a specific rounding mode (truncation). That's probably not what you should be using. Floating point cents gets the best of both worlds (if you set the right rounding mode).
Obviously you can't accumulate cent by cent. You can't even safely accumulate by quarter. Epsilon is too large to do that. I calculate cumulative pnl using std::fma, then multiply AUM with that and round to cents. It's good enough for backtesting, and it shaves a bunch of seconds off the clock.
I see - I guess it's a financial modelling program or similar where the quantities don't represent precise values of money. I was imagining some kind of accounting-like app that would need to be reconciled with real-world balances.
Comments
PSA: do not use floating point for monetary amounts
MS Excel uses floating point, and it's used a ton in finance. Don't use floating-point for monetary amounts if you don't know what rounding mode you've set.
It's somewhat acceptable with double precision floats - never single precision floats.
But far better to just use integer cents.
Integer cents implies a specific rounding mode (truncation). That's probably not what you should be using. Floating point cents gets the best of both worlds (if you set the right rounding mode).
I have used single precision floats in my latest project just to disprove this baloney.
You are using 32 bit floats to represent money?
Does your project correctly calculate $300,000.00 + $0.01, (or even just correctly represent the value $300,000.01) and if so, how?
Obviously you can't accumulate cent by cent. You can't even safely accumulate by quarter. Epsilon is too large to do that. I calculate cumulative pnl using std::fma, then multiply AUM with that and round to cents. It's good enough for backtesting, and it shaves a bunch of seconds off the clock.
I see - I guess it's a financial modelling program or similar where the quantities don't represent precise values of money. I was imagining some kind of accounting-like app that would need to be reconciled with real-world balances.
Yes, we work with futures and the largest transaction is around 1000 qty. It is so rare that most banks have a fat finger alert for such quantities.