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: 2) by FatPhil on Tuesday September 17 2019, @03:13PM (3 children)
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)
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?
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 2) by FatPhil on Wednesday September 18 2019, @08:00AM (1 child)
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
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.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.