Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by martyb on Monday September 16 2019, @01:48PM   Printer-friendly
from the COBOL-is-often-fractionally-better dept.

https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b

Face it: nobody likes fractions, not even computers.

When we talk about COBOL the first question on everyone's mind is always Why are we still using it in so many critical places? Banks are still running COBOL, close to 7% of the GDP is dependent on COBOL in the form of payments from the Centers for Medicare & Medicaid Services, The IRS famously still uses COBOL, airlines still use COBOL (Adam Fletcher dropped my favorite fun fact on this topic in his Systems We Love talk: the reservation number on your ticket used to be just a pointer), lots of critical infrastructure both in the private and public sector still runs on COBOL.

Why?

The traditional answer is deeply cynical. Organizations are lazy, incompetent, stupid. They are cheap: unwilling to invest the money needed upfront to rewrite the whole system in something modern. Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness. And certainly there is a little truth there. Rewriting a mass of spaghetti code is no small task. It is expensive. It is difficult. And if the existing software seems to be working fine there might be little incentive to invest in the project.

But back when I was working with the IRS the old COBOL developers used to tell me: "We tried to rewrite the code in Java and Java couldn't do the calculations right."

[Ed note: The referenced article is extremely readable and clearly explains the differences between floating-point and fixed-point math, as well as providing an example and explanation that clearly shows the tradeoffs.]


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by DannyB on Monday September 16 2019, @05:33PM (10 children)

    by DannyB (5839) Subscriber Badge on Monday September 16 2019, @05:33PM (#894706) Journal

    Don't use floating point for financial calculations.

    Floating point is an approximation overall. Subsets of representable numbers have exact representation. Such as integers, or 0.25. But ten cents 0.10 only has an approximate representation because it is a repeating binary value.

    For money, you want exact values. You don't want to know that approximately this much got deposited to your bank account.

    Floating point is fantastic -- for certain uses. Integers and other financial types are also fantastic for their uses. Just like programming languages have specific use cases that they are good at.

    --
    To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    Starting Score:    1  point
    Moderation   +3  
       Insightful=2, Informative=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by FatPhil on Monday September 16 2019, @05:48PM (9 children)

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Monday September 16 2019, @05:48PM (#894722) Homepage
    Now go off and read some Kahan.

    The *only* example that decimal-heads *ever* come up with is "0.1 isn't exact in binary". Such statements are stupid, and they identify the decimal-heads as stupid decimal-heads. I can think of an infinitude of example numbers that aren't exact in decimal FP. Therefore my example is infinitely more meaningful than yours.

    Decimal FP is only good if the *only* thing you ever do is add, subtract, or multiply by decimally-trivial ratios. It's no better than binary FP if you ever need to take a ratio, or a logarithm, or an exponent, or other things that people who deal with finance are likely to do. Decimal FP is provably less accurate than binary FP - and the proof's in Kahan, now go and read it.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 3, Insightful) by DannyB on Monday September 16 2019, @06:11PM (6 children)

      by DannyB (5839) Subscriber Badge on Monday September 16 2019, @06:11PM (#894739) Journal

      Throughout this topic I have never advocated decimal FP. I advocate integer data types for money. In Java, BigDecimal is often used -- but that is a facade for a BigInteger with a base 10 exponent in order to insert the right decimal point once the BigInteger is converted to base 10 digits.

      There are (rarely) calculations done with money that involve floating point. But that is the exception and not the rule. Floating Point is an approximation. Integers are exact.

      Money has always been an integer data type since before recorded history. The age of computers did not change that.

      --
      To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
      • (Score: 2) by FatPhil on Tuesday September 17 2019, @07:57AM (5 children)

        by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Tuesday September 17 2019, @07:57AM (#895064) Homepage
        > Throughout this topic I have never advocated decimal FP. I advocate integer data types for money.

        Then statements like your "[in binary FP] But ten cents 0.10 only has an approximate representation" are a red herring or deliberately ingenuous, because you can't represent 0.10 as an integer either - the thing you advocate is as useless as thing you were criticising.

        And before you spin up your seemingly imbalanced rotors, any "but I scale by 2 decimal places" can be countered with a "but I can scale by a factor of 100".
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
        • (Score: 2) by DannyB on Tuesday September 17 2019, @02:10PM (4 children)

          by DannyB (5839) Subscriber Badge on Tuesday September 17 2019, @02:10PM (#895144) Journal

          To clarify, since I must have been unclear.

          Don't use FP for money. FP is a type for approximate values, not exact values.

          Money has always been integers since long before computers existed. Use an integer type. (aside: BCD can be thought of as integer type with an implied decimal point somewhere) Integer arithmetic, and I mean 2's compliment, is exact. Even division has an exact quotient and remainder.

          As an example of why not to use floating point for money, I point out the value of 0.10 which perfectly illustrates that there is no exact FP representation for ten cents. There are many values that have no exact FP representation.

          Back in the 1970's, some would say 1960's everyone figured out that FP is inappropriate for money.

          Floating point is excellent for certain uses, just as most tools have an ideal use. Floating point is the wrong tool for the job of representing money.

          Parsing a string like "5.00" into an integer is an exact process. Converting an integer 500 into a string like "5.00" with a decimal point inserted two places from the right, is an exact process. At no point do any approximations exist.

          I hope that is more clear.

          --
          To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
          • (Score: 2) by FatPhil on Tuesday September 17 2019, @03:13PM (3 children)

            by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Tuesday September 17 2019, @03:13PM (#895173) Homepage
            Agree with pretty much all of that.

            However, it is possible to use binary FP correctly for money - the rider is that:
            If your use of FP does not permit you to exactly represent all the values you want it to represent - you're doing it wrong.

            And that's the issue with 1.0 := $1 binary FP.

            If, however, you can exactly represent all the values you want it to represent (e.g. 100.0 = $1 FP, and you only care about results in cents), then there's an isomorphism between that representation and your integer representation, they do the job equally well, one can be turned into the other, and back again, with no loss of information. Both represent integer multiples of an atomic value. The calculations you perform on these values will almost always want to have sub-atom-sized (i.e. fractional in FP context) guards on them, which FP gives you automatically, but you need to know exactly when you should changing from as-close-to-exact-as-possible intermediate values into must-be-an-integer-multiple-of-the-atom representation again (e.g. suitably round()ing an FP). Not needing to flip between FP and FP makes FP easier. Any integer representation must flip into FP in order for the calculations to be performed on it, and flip back out of FP as it leaves the black box - but why bother with the overhead if FP can do it with NOP and round()? The alternative is to write your own FP-avoiding numeric library, which if you have the skill for, you have the skill to use FP correctly anyway.
            --
            Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
            • (Score: 2) by DannyB on Tuesday September 17 2019, @03:34PM (2 children)

              by DannyB (5839) Subscriber Badge on Tuesday September 17 2019, @03:34PM (#895192) Journal

              I one is to use a floating point type to hold exact integers, why not just use an integer type and then never have any doubt?

              --
              To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
              • (Score: 2) by FatPhil on Wednesday September 18 2019, @08:00AM (1 child)

                by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Wednesday September 18 2019, @08:00AM (#895535) Homepage
                I know I do go on a bit, but that was clearly stated above - the overhead of the conversion into and out of the form you actually want to perform the calculations on. With FP it's NOP and round(). Why do unnecessary operations that you don't need to?
                --
                Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
                • (Score: 2) by DannyB on Wednesday September 18 2019, @01:54PM

                  by DannyB (5839) Subscriber Badge on Wednesday September 18 2019, @01:54PM (#895638) Journal

                  For simple arithmetic, round should never be an allowed operation. That is the virtue of integers. It exactly models what currency has always been. Floating point is fantastic if I'm plotting a course to pluto, or doing statistical calculations, or doing 3D rendering and many, many other applications.

                  I won't go on about it, but IMO, floating point has no place when representing currency. (Possibly useful for certain intermediate calculations, but then the result is back to a currency value.) Integer arithmetic (+, -, *, /) is exact. (Division has an exact quotient and remainder.) Converting to / from string representation is exact. The rest of the industry figured this out in the 1970's. Possibly even 1960's.

                  Use floating point for money if you want to. But it probably won't happen on any real commercial type of project. It's the wrong tool for the job.

                  I use Java, as do many others, for the type of work I do, because it is the right tool. (I didn't say perfect. But its combination of attributes is great.) And developer productivity is the major thing to optimize for now. Complain about it if you must, but it is deeply entrenched. As is COBOL -- and I dislike COBOL, but I understand WHY it is.

                  OTOH, Other people use C and C++ for certain things which they are exceedingly good at.

                  Use the right tool for the right job.

                  --
                  To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    • (Score: 2) by DannyB on Monday September 16 2019, @06:13PM

      by DannyB (5839) Subscriber Badge on Monday September 16 2019, @06:13PM (#894741) Journal

      One more thing. Using FP for money is the wrong tool for the wrong job very much like:

      * using a hammer to drive wood screws into wood
      * using C to write accounting software or application software

      There are many software tools, and some of them are better for specific uses than other tools.

      --
      To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
    • (Score: 1, Informative) by Anonymous Coward on Monday September 16 2019, @06:52PM

      by Anonymous Coward on Monday September 16 2019, @06:52PM (#894763)

      ^^^ Proof that a little knowledge leads to a bigger idiot.

      Decimal FP is only good if the *only* thing you ever do is add, subtract, or multiply by decimally-trivial ratios.

      You should reread the OP's post instead of telling him to read Kahan. Decimal trivial ratios are what most financial systems in the world use. And thus the OP's point remains valid.