4 ms·

> Using floats to store monetary values is a bad idea This is waay overstating the case, it very much depends on whether getting the exact answer down to the p

> Using floats to store monetary values is a bad idea This is waay overstating the case, it very much depends on whether getting the exact answer down to the penny matters to you. Worked for a few years at a large investment bank, everything was done in floats because the modeling error of your derivatives pricers would be much larger than the roundoff error, but floats were much more convenient to develop with and faster since you avoided a bunch of casts. Most of the time people think they need things down to the penny, they actually don't. An accountant does not care if you rounded off a few thousand dollars in your $10bn a year income statement. A customer does not really care that you paid them $0.33 three times, rather than $0.33 twice and $0.34 on the third transaction (and fixnums don't even solve this 'extra precision' case without a bunch of extra work).

jimmy1 8y ago
I really want to be generous here: I think your experience is very isolated. I have family that is executive level at a Wall Street bank, they would have you fired over the superfluous loss of a dollar, much less a few thousand dollars because that type of rounding error can end up in the millions over the course of a year if you deal 100+ million dollar transactions 5-6 times a day. Here's how it would go: "Why are we losing a couple of thousands of dollars?" "Well it was easier to just work in floats" "Pack your shit and get the f--- out of here, now."
- endorphone 8y ago
  It really depends upon the context. If they're talking about reporting and forecasts, floats are almost certainly fine. The back end actual storage is generally always numerics, however.
  - PeterisP 8y ago
    Depends on the reporting - if it's legally mandated reporting or tax reporting, then it's going to get audited and any rounding mismatches are definitely not okay.
- zie 8y ago
  I'm totally with you. We write/run financial software for government. We MUST be correct to the penny. Our auditors absolutely check this stuff. We've never done $ math in JS, that just seems like a stupid place to do it. If it's in the browser, you can't trust anything that happens there anyways, as it runs client side, with almost zero security. We happily take $ input via JS on the client, but we just pass it through, and let the server(s) handle the actual math.
- smallnamespace 8y ago
  > because that type of rounding error can end up in the millions over the course of a year if you deal 100+ million dollar transactions 5-6 times a day. I think we're talking past each other a bit. Financial products pricers themselves only have as much precision as the inputs, which in many cases might only have 3-5 significant figures. Using arbitrary precision math doesn't buy you any more precision than what your inputs have. Remember that a 64-bit float gives you 52 bits ~ 14 decimal digits of precision, so unless you're doing something that has terrible numerical stability, the error of your model assumptions and inputs will always dominate floating point error. It doesn't matter if your model spits out $XXXXXX.08 or $XXXXXX.15 - both answers are essentially the same. Just to provide context, we were pricing deals with notional amounts in the billions and PVs up to tens of millions. Note that we're comfortable doing nuclear bomb simulations or climate models using FP64 floating point calculations, for the same reasons — the error in your model is bigger anyway. > they would have you fired over the superfluous loss of a dollar The handling of customer accounts is different at a bank since you're not supposed to be creating or losing money out of thin air—that's the Fed's job. But that's not what the article claims—it claims that any monetary amount, anywhere, should never use a float, which IMO overstates things from both a business and maths standpoint.
btilly 8y ago
And I had the misfortune for working for a few years with bond modeling software that used floats internally. Turns out that the first thing a financial analyst does to compare two implementations of a bond securitization model is to look at the pennies. If those tie out, then you're good. But if your software predicts money off by a dime in a billion dollar model deal, the analyst WILL notice and WILL try to get to the bottom of it. Yeah, floating point roundoff error seems like it should be immaterial. However it can matter a whole lot.
- swish_bob 8y ago
  They need some way to validate things, and it turns out if the number isn't exactly the same when they run their samples they don't trust any of them. For at least some value of them. The founder at the last place I worked at was famously difficult to satisfy because of this. You couldn't even begin to talk about how you were presenting data to him unless you were absolutely sure the numbers in your mockup were correct. He just couldn't see past an "incorrect" value when dealing with faked data ...

jimmy1 8y ago

I really want to be generous here: I think your experience is very isolated. I have family that is executive level at a Wall Street bank, they would have you fired over the superfluous loss of a dollar, much less a few thousand dollars because that type of rounding error can end up in the millions over the course of a year if you deal 100+ million dollar transactions 5-6 times a day. Here's how it would go: "Why are we losing a couple of thousands of dollars?" "Well it was easier to just work in floats" "Pack your shit and get the f--- out of here, now."

endorphone 8y ago
It really depends upon the context. If they're talking about reporting and forecasts, floats are almost certainly fine. The back end actual storage is generally always numerics, however.
- PeterisP 8y ago
  Depends on the reporting - if it's legally mandated reporting or tax reporting, then it's going to get audited and any rounding mismatches are definitely not okay.
zie 8y ago
I'm totally with you. We write/run financial software for government. We MUST be correct to the penny. Our auditors absolutely check this stuff. We've never done $ math in JS, that just seems like a stupid place to do it. If it's in the browser, you can't trust anything that happens there anyways, as it runs client side, with almost zero security. We happily take $ input via JS on the client, but we just pass it through, and let the server(s) handle the actual math.
smallnamespace 8y ago
> because that type of rounding error can end up in the millions over the course of a year if you deal 100+ million dollar transactions 5-6 times a day. I think we're talking past each other a bit. Financial products pricers themselves only have as much precision as the inputs, which in many cases might only have 3-5 significant figures. Using arbitrary precision math doesn't buy you any more precision than what your inputs have. Remember that a 64-bit float gives you 52 bits ~ 14 decimal digits of precision, so unless you're doing something that has terrible numerical stability, the error of your model assumptions and inputs will always dominate floating point error. It doesn't matter if your model spits out $XXXXXX.08 or $XXXXXX.15 - both answers are essentially the same. Just to provide context, we were pricing deals with notional amounts in the billions and PVs up to tens of millions. Note that we're comfortable doing nuclear bomb simulations or climate models using FP64 floating point calculations, for the same reasons — the error in your model is bigger anyway. > they would have you fired over the superfluous loss of a dollar The handling of customer accounts is different at a bank since you're not supposed to be creating or losing money out of thin air—that's the Fed's job. But that's not what the article claims—it claims that any monetary amount, anywhere, should never use a float, which IMO overstates things from both a business and maths standpoint.

btilly 8y ago

And I had the misfortune for working for a few years with bond modeling software that used floats internally. Turns out that the first thing a financial analyst does to compare two implementations of a bond securitization model is to look at the pennies. If those tie out, then you're good. But if your software predicts money off by a dime in a billion dollar model deal, the analyst WILL notice and WILL try to get to the bottom of it. Yeah, floating point roundoff error seems like it should be immaterial. However it can matter a whole lot.

swish_bob 8y ago
They need some way to validate things, and it turns out if the number isn't exactly the same when they run their samples they don't trust any of them. For at least some value of them. The founder at the last place I worked at was famously difficult to satisfy because of this. You couldn't even begin to talk about how you were presenting data to him unless you were absolutely sure the numbers in your mockup were correct. He just couldn't see past an "incorrect" value when dealing with faked data ...