3 ms·

In fact, you want to use something like Java's BigDecimal for financial calculations: https://dzone.com/articles/never-use-float-and-double-for-monetary-calcul

In fact, you want to use something like Java's BigDecimal for financial calculations: https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio https://dzone.com/articles/never-use-float-and-double-for-mo...

jqpabc123 4y ago
Yes, that works --- but you can pay a significant price in terms of efficiency and storage headaches. It all depends on your needs. 64 bit integers fit natively within modern processor registers (read max. possible speed) and are still reasonably efficient even when implemented in 32 bit processors. My simple suggestions to avoid loss of of significance, comparison decoherence, "mystery penny" problems and storage convenience are these. - Use 64 bit integers for monetary amounts expressed in pennies. Format as desired for display/printing. - Use 32 bit integers for annual interest rates with amounts scaled to 3 decimals (x1000). For example, 8.000% would be stored as 8000. 8.259% would be 8259. If you think you need more decimals (personally, I doubt it), go for it --- just be sure your math is scaled appropriately. - Round and store amounts paid/due to the nearest penny using "banker's rounding". This in itself can cause some minor loss of accuracy (piecewise rounding) which (if any) should be reflected in the "final" payment. - Temporarily use 4 additional decimals for any multiplication or division intensive calculation. Round and return a final resultant to the nearest penny. - This generally works just fine for routine calculations involving amounts below $100 billion or so which is probably 99.9% of financial apps. Simple totals can go up to $ trillion range. "BigDecimal" (which is really infinite range integer math with library routines available in many different languages) might be a candidate for the remaining 0.1% but personally; all things considered, I would investigate 96 or 128 bit integer math first if more range is needed. C/C++ and Rust have an int128 type. Your mileage may vary.
- SideQuark 4y ago
  >but you can pay a significant price in terms of efficiency and storage headaches Yet the code you posted above as using int64 does not in fact work using int64, it requires arbitrary sized integers as I demonstrated above. Did you even check your code? Your example above has the (P*R) term overflowing leading to nonsense results. Man this is funny - you somehow thought you were using int64 in your calcs but you were not :)
- hnews_account_1 4y ago
  You’re misunderstanding the problem. It isn’t storage, it is calculation. You cannot do away with decimals because calculations are not always linear. There are several logarithms, exponents and root finding algorithms used in finance which you’d have to write several additional rules for if you can’t represent decimals. It’s not like mathematicians thought decimals were just a convenience so you don’t have to show large integers. They’re fundamentally not integers.
  - jqpabc123 4y ago
    As stated below in this thread: Perfectly valid use cases for floats do exist --- but these are a lot fewer than what I see being done in the real world. Most simple accounting applications involving time and money can be better addressed without them.
    - hnews_account_1 4y ago
      Your arguments all over this thread are not “simple accounting applications”. Mortgages are ridiculously complicated. Even if they aren’t, the simplest of prepayment models requires exponents and fractions all of which will fail spectacularly if your system used just a fixed decimal range. When you first mentioned it in this thread, I thought you meant like simple surface level applications or accounting things, not heavily complex stuff like mortgages or derivatives. The latter require precise math in their (very non linear) modeling. You cannot eschew floats in that case.
      - jqpabc123 4y ago
        Mortgages are ridiculously complicated. All simple addition, subtraction, multiplication and division. This stuff was invented long before computers --- like way back in ancient Babylon. will fail spectacularly if your system used just a fixed decimal range. Really? Wonder how the US economy gets by on a fixed decimal range? Have you ever paid for anything in fractions of a penny? You cannot eschew floats in that case. I'm sure it's possible to craft a "derivative" that no one understands using higher level math. But accounting and mortgages are all built around simple 4 function arithmetic. All you really need to do is insure you have enough range for penny accuracy and you can stumble by somehow. See the routine I posted above in this thread. NOTE: Nothing prevents you from using floating point math in an isolated routine if you think you really need it. My real objection is using FP everywhere, including storage. This creates lots of potential problems that can be avoided by simply using integers. And with 64 bit processors, the required math is very efficient.

jqpabc123 4y ago

Yes, that works --- but you can pay a significant price in terms of efficiency and storage headaches. It all depends on your needs. 64 bit integers fit natively within modern processor registers (read max. possible speed) and are still reasonably efficient even when implemented in 32 bit processors. My simple suggestions to avoid loss of of significance, comparison decoherence, "mystery penny" problems and storage convenience are these. - Use 64 bit integers for monetary amounts expressed in pennies. Format as desired for display/printing. - Use 32 bit integers for annual interest rates with amounts scaled to 3 decimals (x1000). For example, 8.000% would be stored as 8000. 8.259% would be 8259. If you think you need more decimals (personally, I doubt it), go for it --- just be sure your math is scaled appropriately. - Round and store amounts paid/due to the nearest penny using "banker's rounding". This in itself can cause some minor loss of accuracy (piecewise rounding) which (if any) should be reflected in the "final" payment. - Temporarily use 4 additional decimals for any multiplication or division intensive calculation. Round and return a final resultant to the nearest penny. - This generally works just fine for routine calculations involving amounts below $100 billion or so which is probably 99.9% of financial apps. Simple totals can go up to $ trillion range. "BigDecimal" (which is really infinite range integer math with library routines available in many different languages) might be a candidate for the remaining 0.1% but personally; all things considered, I would investigate 96 or 128 bit integer math first if more range is needed. C/C++ and Rust have an int128 type. Your mileage may vary.

SideQuark 4y ago
>but you can pay a significant price in terms of efficiency and storage headaches Yet the code you posted above as using int64 does not in fact work using int64, it requires arbitrary sized integers as I demonstrated above. Did you even check your code? Your example above has the (P*R) term overflowing leading to nonsense results. Man this is funny - you somehow thought you were using int64 in your calcs but you were not :)
hnews_account_1 4y ago
You’re misunderstanding the problem. It isn’t storage, it is calculation. You cannot do away with decimals because calculations are not always linear. There are several logarithms, exponents and root finding algorithms used in finance which you’d have to write several additional rules for if you can’t represent decimals. It’s not like mathematicians thought decimals were just a convenience so you don’t have to show large integers. They’re fundamentally not integers.
- jqpabc123 4y ago
  As stated below in this thread: Perfectly valid use cases for floats do exist --- but these are a lot fewer than what I see being done in the real world. Most simple accounting applications involving time and money can be better addressed without them.
  - hnews_account_1 4y ago
    Your arguments all over this thread are not “simple accounting applications”. Mortgages are ridiculously complicated. Even if they aren’t, the simplest of prepayment models requires exponents and fractions all of which will fail spectacularly if your system used just a fixed decimal range. When you first mentioned it in this thread, I thought you meant like simple surface level applications or accounting things, not heavily complex stuff like mortgages or derivatives. The latter require precise math in their (very non linear) modeling. You cannot eschew floats in that case.
    - jqpabc123 4y ago
      Mortgages are ridiculously complicated. All simple addition, subtraction, multiplication and division. This stuff was invented long before computers --- like way back in ancient Babylon. will fail spectacularly if your system used just a fixed decimal range. Really? Wonder how the US economy gets by on a fixed decimal range? Have you ever paid for anything in fractions of a penny? You cannot eschew floats in that case. I'm sure it's possible to craft a "derivative" that no one understands using higher level math. But accounting and mortgages are all built around simple 4 function arithmetic. All you really need to do is insure you have enough range for penny accuracy and you can stumble by somehow. See the routine I posted above in this thread. NOTE: Nothing prevents you from using floating point math in an isolated routine if you think you really need it. My real objection is using FP everywhere, including storage. This creates lots of potential problems that can be avoided by simply using integers. And with 64 bit processors, the required math is very efficient.