Thread

1. amelius · 1790855294 · 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 (the type of float Javascript uses in every browser).

   1. sluukkonen · 1790858843 · 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 · 1790859662 · 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 · 1790867241 · 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 · 1790876135 · focus · HN ↗

               For many years, nobody has supported decimal numbers in hardware, except IBM (the deprecated instructions of Intel 8086 and 8087 do not count).

               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 · 1790899525 · focus · HN ↗

                  [dead]

               2. OGWhales · 1790958668 · 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...

Unofficial Hacker News client; not affiliated with Y Combinator.