‹ BackHN Continuity

Thread

Adding Floating-Point Decimals for Fun and Profit

61 points · 35 comments · ibobev

Loading the complete thread in the background. This saved snapshot is available now. Refresh

  1. amelius · · focus · HN ↗
    > Many people know that you shouldn’t do decimal calculations, such as those involving U.S. dollars and cents, with the floating-point numbers in most programming languages. This is because decimal numbers can’t be expressed exactly as such floating-point numbers, so you will encounter rounding errors.

    Why not, rounding to the nearest cent is going to be much less precise for any realistic amount of dollars when using 64 bit floats.

    1. glimshe · · focus · HN ↗
      The rounding behavior with true decimals is easy to control and understand across number magnitudes and doesn't suffer from platform specific quirks like floats/doubles.

      The article's images clearly show the rounding error mess your get without decimals.

      1. amelius · · focus · HN ↗
        But the rounding errors are way down in the nano-cents. Not worrying about them is cheaper!
        1. glimshe · · focus · HN ↗
          If you're calculating your monthly expenses that's okay, but across millions of transactions of arbitrary amounts, something financial systems do regularly, aggregates start not adding up and you don't know where the money went.
        2. andreareina · · focus · HN ↗
          The decimal library worries about rounding, that's basically free. With floats you need to decide when to use rounding (because you don't want to show a balance of -0.000000086) and it's more difficult to use automatic checks for the same reason.
      2. sobriquet9 · · focus · HN ↗
        There's still catastrophic cancellation, where subtracting two large numbers that are very close results in an answer with reduced precision.
    2. knorker · · focus · HN ↗
      "The nearest cent" is already a bad assumption. Should IEEE 754 representation dictate taxes and money splitting?

      You could end up with splitting an account down the middle, and ending up with an extra cent being created out of thin air, or one destroyed. In billions of transactions each day, this could be a problem for balancing books when there is no longer any equality check.

      When not using floats, the rules and checks become more… deterministic, if you don't mind stretching the definition of that word a bit.

    3. sluukkonen · · focus · HN ↗
      It’s easier just to use a proper decimal type than to remember all of the ways where using floats will bite you in the ass. The behavior is unintuitive even in trivial examples. Code like

        amount_due = 0.10 + 0.20
  amount_paid = 0.30
  
  if amount_paid >= amount_due:
      print("PAID")
  else:
      print("OUTSTANDING")
      will print “OUTSTANDING”.
      1. adrian_b · · focus · HN ↗
        True, but those who do not use decimal floating-point numbers do not use such binary floating-point numbers.

        They use binary fixed-point numbers/integers, where such computations are exact, while not having the huge computational overhead of decimal floating-point numbers.

        1. OGWhales · · focus · HN ↗
          Indeed, though this is platform dependent. Mainframes have strong hardware support for decimal fixed-point arithmetic, making it the preferred representation for fixed-scale business data, though conceptually it's very similar to binary fixed-point.

          Decimal floating-point is also hardware-supported, so it doesn’t carry the same computational overhead it does on platforms where it must be implemented in software.

          1. adrian_b · · focus · HN ↗
            For many years, nobody has supported decimal numbers in hardware, except IBM.

            IBM has done this, despite it being an inferior technical solution, because it binds those who choose it to IBM hardware.

            Programming currency operations with decimal floating-point numbers is easier for naive programmers.

            Even on IBM mainframes, implementing currency operations using 64-bit or 128-bit integers is much faster and less resource-consuming than with decimal numbers, but the implementation of some of the operations can be a little tricky, when it must be guaranteed that no loss of precision may occur.

            I think that I might have seen recently an announcement from someone else than IBM who has introduced hardware support for decimal floating-point numbers, perhaps from Fujitsu. In any case, whoever introduces such hardware support does it to lure some customers to migrate from IBM to them, and not because it were a good solution for implementing operations with money.

            1. OGWhales · · focus · HN ↗

              [dead]

            2. OGWhales · · focus · HN ↗
              I came across this article today, by pure chance, and thought you might enjoy it: <a href="https:&#x2F;&#x2F;cs-syd.eu&#x2F;posts&#x2F;2022-08-22-how-to-deal-with-money-in-software" rel="nofollow">https:&#x2F;&#x2F;cs-syd.eu&#x2F;posts&#x2F;2022-08-22-how-to-deal-with-money-in...
      2. AlotOfReading · · focus · HN ↗
        Decimals can bite you in the ass too. Try dividing by 3, or using transcendental functions.

        Changing representations isn&#x27;t a substitute for the numerical analysis you should be doing for financial calcs.

      3. vatsachak · · focus · HN ↗
        threshold = 1e-9 enters the chat
    4. bee_rider · · focus · HN ↗
      I think there’s an implicit assumption with this sort of “use a special decimal type” advice: that the rules of the transactions are defined in terms of decimal rounding.

      I mean, just as an example, your saving account interest could be computed continuously, e^(rt), which would obviously be better approximated in floating point. But they won’t have to do any approximation if they write the contract so that it compounds nightly and is rounded to the nearest, whatever, tenth of a cent (which means that the rounding isn’t an approximation at all, it is part of the definition of the value being represented).

    5. clickety_clack · · focus · HN ↗
      Regular people understand the decimal system and they understand rounding in that system. The floating point system is a different system that they don&#x27;t understand. People need to trust that the mechanics of payments are correct or they feel like they&#x27;re being ripped off, and you can&#x27;t really trust what you don&#x27;t understand. Rounding of decimal pennies means that people get payments systems they can trust at the cost of precision.
  2. sieve · · focus · HN ↗
    Accounting has the concept of materiality. But you still want the figures to tally to the last cent.

    One way to do this is to separate the computation&#x2F;storage and presentation layer: use integers to store values as cents for computation&#x2F;storage and only convert to dollars+cents on display. But then someone might suddenly demand three digits after the decimal point and you cannot go about changing every stored value just because the logic changed in one part of the application. So, using decimals is the safer choice.

    I prefer integers for my plain text ledger software though because the format is in my control.

    1. hansvm · · focus · HN ↗
      I like using rational types for that sort of thing.
    2. PaulDavisThe1st · · focus · HN ↗
      This gets tricky when it comes to dealing with currency conversion. On my most recent credit card bill, foreign currency transactions show an exchange rate with 10 digits of precision.
      1. adrian_b · · focus · HN ↗
        When implementing currency with integers, actually with fixed-point numbers, there is no difficulty in having an exchange rate with the same precision as the integer format, i.e. up to 18-19 digits for 64-bit integers.

        You just have to implement the conversion function carefully, i.e. the exchange ratio would actually be represented not by a single number, but by a ratio of suitable integers, to ensure no loss of precision during the conversion done by multiplication with extended result and then division.

    3. adrian_b · · focus · HN ↗
      Using 64-bit integers as a count of a hundredth or of a thousandth part of a cent should be enough for more purposes.

      If you want to be able to count trillions of trillions of dollars with a resolution of the millionth part of a cent, than you can use 128-bit integers.

      Computing exactly with 128-bit integers is many times faster than computing only approximately with decimal floating-point numbers and it requires less memory storage for the same dynamic range.

      1. fourier54 · · focus · HN ↗
        Actually 128 int uses 2 times the storage for less dynamic range. I agree however that for financial applications int is always better. You don&#x27;t want float dynamic range on finance calculations
        1. adrian_b · · focus · HN ↗
          You are right, I forgot that nowadays standard decimal floating-point numbers do not use BCD encoding any more, but they pack 3 decimal digits into each 10 bits.

          This means that the 64-bit decimal64 format still provides an acceptable precision of 16 digits, even if it is lower than for 64-bit integers, which provide over 18 digits.

          If the goal is to avoid rounding, 64-bit binary integers are still superior to decimal64, due to the availability of more significant digits, but due to its scale factor decimal64 is superior if you want to express a huge amount of money while allowing rounding, which would probably be needed only for amounts greater than the budgets of all countries together.

          You are right that decimal64 provides a greater dynamic range than 128-bit binary integers, but even so the dynamic range of 128-bit integers is many orders of magnitude greater than needed for any imaginable amount of money, while providing exact operations performed at a speed many times greater than for decimal64.

          On computers without hardware support for the IEEE standard decimal formats, much faster operations with decimal floating-point numbers can be implemented if they are not represented like in the standard, but as a product between a binary integer and an integer power of ten.

    4. nly · · focus · HN ↗
      I&#x27;ve worked at 3 separate trading companies, each making millions or billions in profit, that just use doubles for prices and cash values.

      Just before you send something on the wire you just make sure you serialize (part of which is rounding) to the appropriate ticksize.

      Generally speaking tick sizes (cents, valid trade price increments, whatever) are many orders of magnitude greater than any possible calculation error, so rounding to nearest just works

      1. sieve · · focus · HN ↗
        My concern is something fairly boring but important nevertheless: your bills&#x2F;invoices, receipts, credit&#x2F;debit notes, contract notes, trial balances, ledgers&#x2F;statements etc.

        Internally, you may use whatever precision&#x2F;scale you want, and compute using doubles or decimals or integers. But I want to see 100.01 - (37.29 + 41.63) = 100.01 - 78.92 = 21.09 in all of these statements.

  3. krige · · focus · HN ↗
    Possibly the first case I&#x27;ve encountered where image loaded before the text. A grid of 1px rectangles? How unsettling.
  4. jgalt212 · · focus · HN ↗
    &gt; Many people know that you shouldn’t do decimal calculations, such as those involving U.S. dollars and cents, with the floating-point numbers in most programming languages. This is because decimal numbers can’t be expressed exactly as such floating-point numbers, so you will encounter rounding errors.

    Decimals or pennies, you still have rounding errors. For example, if your contract is $100 &#x2F; year. You will get the full $100 if you bill yearly, quarterly, or semi-annually. But if you bill monthly, no matter if you deal in pennies or fractional dollars, the sum total of your invoices for the year will be less than $100.

    1. gottheUIblues · · focus · HN ↗
      Bill 8 months at $8.33 and 4 months at $8.34?
      1. mytailorisrich · · focus · HN ↗
        Having 11 equal payments and a 1st or 12th one of a different amount to make the total exact is a fairly common way of dealing with this.
      2. jgalt212 · · focus · HN ↗
        Yeah, I know there&#x27;s more than one way to skin a cat. My point is that storing all accounting values in pennies is overrated.
      3. astrobe_ · · focus · HN ↗
        If you&#x27;re going for ad hoc solution to that specific problem, just charge $99&#x2F;year or $102&#x2F;year instead, depending on how you feel like about profit margins.
    2. nitwit005 · · focus · HN ↗
      Usually the contract itself specifies how that should work. You often see a schedule of payments, and how dealing with early cancelation should work.
  5. sobriquet9 · · focus · HN ↗
    Besides Python’s fractions, there are also constructive reals, exemplified by Android calculator where you can swipe any answer to get as many digits as you want.
  6. NaoEhSavio · · focus · HN ↗

    [dead]

  7. kphorn · · focus · HN ↗
    Great blog post by Peter Gibbons and Michael Bolton about their work at Initech

    <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yZjCQ3T5yXo" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=yZjCQ3T5yXo

    &quot;all right so when the subroutine compounds the interest, it uses all of these extra decimal places that just get rounded off. So we simplified the whole thing, we round them all down and drop the remainder... in to an account that we opened&quot;

  8. dublin · · focus · HN ↗
    It&#x27;s the 21st century: All computers should do Base10 math by default. We have cycles to burn, and some ARM and IBM CPUs even have decimal math instructions.

    Only true propellerheaded programmers should ever see or care about binary floating point issues. NB: I do massively scalable wireless data collection networks for IoT (using variously, floats, doubles, and half-precision, as called for by their use case), so I&#x27;m one of those people, but ordinary folks and users should never, ever, be impacted by binary imprecision.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.