5 ms·

Why would you ever use floating point for money? You're just asking for rounding errors if you actually use the range, aren't you?

protomyth 11y ago
Using floating point for quantities of commodities is an equally bad idea. Conversations and rounding will kill you.
wtallis 11y ago
Has any economic calculation or accounting ever actually had 16 significant digits? If you're talking about $360 trillion, you can only pretend to have a quantity that's correct to the last cent; even if you used sufficient precision for the calculations, your number cannot be connected to the real world with that much precision.
- detaro 11y ago
  Less valuable currencies have bigger numbers (eg 1 USD = 17472.5 BYR), so suddenly it's only a few million USD worth of money. Even worse for extreme examples of inflation. Not that the individual unit is actually worth anything there, but calculating it with enough precision is probably easier than the regulation to deal with where money is allowed to disappear or to suddenly exist.
  - wtallis 11y ago
    Less valuable currencies produce bigger numbers, but they don't yield more precise specification of value. Even though it is severely inflated, the smallest active denomination of BYR is only a little smaller than a US cent, and any real-world scenario involving large quantities (larger than the entire supply of BYR!) will easily tolerate rounding to that precision.
    - detaro 11y ago
      Yeah, the real world value is not very high, but I would be surprised if you officially could accept errors larger than the smallest unit and wouldn't get potentially into trouble when something adds up wrong.
kazinator 11y ago
But the error is in the 17th place: insignificant. Before such an error represents single digit pennies, you're looking at astronomical money. The main problem with ordinary, IEEE 754 binary floating point for money is that even run-of-the-mill numbers like $123.45 (nowhere near astronomical) exhibit serious problems when added together, due to 0.45 not being representable exactly in binary, and causing cumulative rounding errors. This is cured by decimal floating point, which represents $123.45 exactly. If you deal with quantities that stay within the 16 digits of precision, you will nigh hardly have a problem.
- wiz21 11y ago
  I use to think like that, but then there's practice over theory : 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" 2/ When people are faced with "I have to have this number with 2 decimals", they sometimes write a = round(a * 100)/100; forgetting that 'a' is a float (or double), and then they completely forget that the new 'a' is just not accurate. 3/ Issues with floats arise on simple operations such as addition. And people tend to think that simple operations have no rounding issues. It'd be perfectly valid to work with floating point for money; but then you have to take care of the rounding issues much more often than with fixed point (or BigDecimal if you're in the java world). Once you use those BigDecimal, addition becomes safe, and "manual" rounding works as expected (when you round to 2 decimals, you get exactly 2, not an approximation). So, after project managing several teams of developers, I can safely say that although F.P. can be fine, most people can't handle the mental load of thinking about rounding issues on each math operation they do (and "most people" includes myself). That's a human risk management issue, not a theoritical one.
  - krylon 11y ago
    > 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" So true! In a previous job, I had to work with code that did computational geometry, and I quickly learnt that lesson the hard way. I shared an office with my supervisor, who spent a lot of time on the phone, so I also learnt not to curse like a sailor, a lesson I appreciate, in retrospect, almost as much.
deleted 11y ago
[deleted]

protomyth 11y ago

Using floating point for quantities of commodities is an equally bad idea. Conversations and rounding will kill you.

wtallis 11y ago

Has any economic calculation or accounting ever actually had 16 significant digits? If you're talking about $360 trillion, you can only pretend to have a quantity that's correct to the last cent; even if you used sufficient precision for the calculations, your number cannot be connected to the real world with that much precision.

detaro 11y ago
Less valuable currencies have bigger numbers (eg 1 USD = 17472.5 BYR), so suddenly it's only a few million USD worth of money. Even worse for extreme examples of inflation. Not that the individual unit is actually worth anything there, but calculating it with enough precision is probably easier than the regulation to deal with where money is allowed to disappear or to suddenly exist.
- wtallis 11y ago
  Less valuable currencies produce bigger numbers, but they don't yield more precise specification of value. Even though it is severely inflated, the smallest active denomination of BYR is only a little smaller than a US cent, and any real-world scenario involving large quantities (larger than the entire supply of BYR!) will easily tolerate rounding to that precision.
  - detaro 11y ago
    Yeah, the real world value is not very high, but I would be surprised if you officially could accept errors larger than the smallest unit and wouldn't get potentially into trouble when something adds up wrong.

kazinator 11y ago

But the error is in the 17th place: insignificant. Before such an error represents single digit pennies, you're looking at astronomical money. The main problem with ordinary, IEEE 754 binary floating point for money is that even run-of-the-mill numbers like $123.45 (nowhere near astronomical) exhibit serious problems when added together, due to 0.45 not being representable exactly in binary, and causing cumulative rounding errors. This is cured by decimal floating point, which represents $123.45 exactly. If you deal with quantities that stay within the 16 digits of precision, you will nigh hardly have a problem.

wiz21 11y ago
I use to think like that, but then there's practice over theory : 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" 2/ When people are faced with "I have to have this number with 2 decimals", they sometimes write a = round(a * 100)/100; forgetting that 'a' is a float (or double), and then they completely forget that the new 'a' is just not accurate. 3/ Issues with floats arise on simple operations such as addition. And people tend to think that simple operations have no rounding issues. It'd be perfectly valid to work with floating point for money; but then you have to take care of the rounding issues much more often than with fixed point (or BigDecimal if you're in the java world). Once you use those BigDecimal, addition becomes safe, and "manual" rounding works as expected (when you round to 2 decimals, you get exactly 2, not an approximation). So, after project managing several teams of developers, I can safely say that although F.P. can be fine, most people can't handle the mental load of thinking about rounding issues on each math operation they do (and "most people" includes myself). That's a human risk management issue, not a theoritical one.
- krylon 11y ago
  > 1/ When a coder thinks about writing "if a <= b", then he writes "if a <= b", he easily forgets that he should write "if a <= b + epsilon()" So true! In a previous job, I had to work with code that did computational geometry, and I quickly learnt that lesson the hard way. I shared an office with my supervisor, who spent a lot of time on the phone, so I also learnt not to curse like a sailor, a lesson I appreciate, in retrospect, almost as much.

deleted 11y ago

[deleted]