SoylentNews is people
SoylentNews
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.]
(Score: 0) by Anonymous Coward on Monday September 16 2019, @11:01PM (5 children)
Your scaled integer solution (storing everything as an integer penny amount, for example) works when you are doing simple sums, differences, and integer multiplications. It fails everywhere everywhere else.
integer + integer -> integer
integer - integer -> integer
integer * integer -> integer
integer / integer -> real
As a consequence of the above rules,
it is also true that:
integer * (fraction) -> real
So your scaled integer system is not in any way a general solution.
Sure, you could add routines to handle the operations I noted above that result in real numbers with more code, but at that point you have just re-invented decimal arithmetic.
I guess you could buy yourself some "time" to keep using scaled integers by scaling to a large decimal number, you still run into rounding issues which eventually will lead to accumulated
inaccuracies, plus it's a pain and errorprone to manage the decimal point "outside of the code."
(Score: 1) by jurov on Tuesday September 17 2019, @12:01AM (2 children)
We are not talking about general solutions for everything.
We are talking about money amounts and explicit rounding. With scaled integers, you can sit down with the formula and determine the required precision beforehand, only basic arithmetic understanding is required.
Say you need to apply some % discount. Well then, with scaled integers: multiply the price by (100 - discount), then if you want rounding up, add 1 and lastly, divide by 100 to get discounted price (assuming integer division rounds down).
With floating point numbers it is altogether unclear if we can rely on this approach. That's the point of this article and whole discussion.
(Score: 0) by Anonymous Coward on Tuesday September 17 2019, @01:23AM (1 child)
Or you just use a language with full support for decimal arithmetic and happily and quickly get on with writing the REST of your program, secure in the knowledge that basic arithmetic will be correct. There is no excuse to do it any other way unless you are writing embedded systems code for an 8 bit processor or Wall Street high frequency transaction systems. Stop writing brittle code!
(Score: 2) by theluggage on Tuesday September 17 2019, @10:40AM
Well, that includes just about every serious language in use today - if decimal math isn't built into the language (Java, Python), there will be a library (C/C++). So it is certainly not an excuse for sticking with COBOL.
It is code that ignores appropriate precision that is brittle. If your algorithm would - in binary - magnify the difference between 0.1 and 0.09999999999999012964 into a significant bottom line error, then it may well do the same - in decimal - with the different between 1/6 and 0.166666666666666667, let alone the +/- 0.005 margin of error in every input value rounded to the nearest cent.
(Score: 2) by theluggage on Tuesday September 17 2019, @09:31AM (1 child)
So does decimal, which can no more represent every real number than binary can. E.g. 1/6 = 0.166666...
(Score: 0) by Anonymous Coward on Tuesday September 17 2019, @11:59AM
Decimal numbers are used to represent currency.
Currency is not arbitrary fractions, but short, terminating decimal fractions.
For example, we talk of dollars and cents, and those cents are integers in themselves.
It is this domain where you need to use decimal arithmetic.
The fact that 1/6 doesn't have a terminating decimal representation (your example) is not limiting because in business calculations typically you use either short, terminating fractions in decimal -or- if you do something like divide by 6, you still want the math done correctly for your decimal numbers and rounded correctly as well.
There are multiple rounding algorithms used in finance, and each depends on a decimal representation in the fraction, so rounding ALONE requires decimal.
You can't use a scaled integer representation and get correct rounding.