A GCC COBOL status report

Posted Feb 13, 2023 18:39 UTC (Mon) by mmaug (subscriber, #61003)
In reply to: A GCC COBOL status report by pbonzini
Parent article: A GCC COBOL status report

Being a "data" guy, the primary distinction of COBOL was its focus on DECIMAL arithmetic rather than binary. Since very few modern processors (if any) have native support for BCD encoded numerics, the operations must be done in library functions. That will lead to poor performance relative to pure binary numeric processing. However, for fiscal data (Payroll, billing, accounting, ...), there are no IEEE floats to approximate results and lead to Office Space-style penny rounding. But with 128-bit integers, you could do handle most problems with scaled integers and avoid floating point.

Aside: the MicroVAX was a single chip implementation of the VAX architecture which implemented about 100 of the most common/needed by VMS instructions, out of the 300+ possible, in hardware. The rest were software interrupts to emulate the instruction in VAX code. The instructions left off were the complex string and BCD instructions. Sales people were very careful to warn you not to buy a MicroVAX-based machine if you used COBOL (or DIBOL [DEC's Business language])

A GCC COBOL status report

Posted Feb 13, 2023 19:44 UTC (Mon) by Wol (subscriber, #4433) [Link]

> there are no IEEE floats to approximate results and lead to Office Space-style penny rounding. But with 128-bit integers, you could do handle most problems with scaled integers and avoid floating point.

Which is why Pick/MV natively handles *fixed* point numbers.

Okay, that brings its own set of challenges, but it certainly makes handling rounding problems easier when dealing with objects like pennies and Chinook helicopters.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 13, 2023 20:58 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

This seems like a good example of needing to understand the problem space in order to understand the solution. It turns out that payroll and accounting have specific needs different from most computer programs. Their programs have to calculate numbers according to accounting rules, which are sufficiently different from standard floating point math that you can't just use floats and assume everything will come out right. COBOL is built to handle those financial calculations, so people who really need that accuracy use it. Those are the user requirements, and they are really non-negotiable.

A GCC COBOL status report

Posted Feb 13, 2023 23:15 UTC (Mon) by pbonzini (subscriber, #60935) [Link]

Additions and divisions are not that bad; on 16-bit machines it takes about 10 instructions to do an add of a 4-digit value, but on 64-bit machines you can use the same number of instructions for 16 digits[1]. Multiplications and divisions are very slow. But in practice programs would spend more time doing I/O than decimal arithmetic.

(Many many years ago I spent quite some time admiring the decimal arithmetic routines that were generated by the Realia COBOL compiler. The compiler itself was pretty fast, and written itself in COBOL!)

[1] http://web.archive.org/web/20180831035425/http://hackersd... search for "arithmetic on BCD values"

A GCC COBOL status report

Posted Feb 16, 2023 7:34 UTC (Thu) by smurf (subscriber, #17840) [Link] (7 responses)

Well, if you want reasonable speed *and* payroll accuracy , today you'd probably use rational numbers (i.e. fractions) as your basic data type. Or 1/1000th cent or whatever (i.e. fractions with a fixed denominator). In fact, that's what I'd expect a reasonable optimizing compiler to convert all these pesky DECIMALs to. Even with inflation / govenments throwing money about like crazy, today's 64-bit integers should remain sufficient for that.

A GCC COBOL status report

Posted Feb 16, 2023 9:56 UTC (Thu) by geert (subscriber, #98403) [Link] (6 responses)

Always using 1/1000th of a cent is overkill, and may even be wrong.
When it comes to money, there are strict rounding rules to follow.
E.g. everything is rounded to a cent. Except for fuel prices, which must use an accuracy of 0.1 cent.
Cash amounts may have to be rounded to 5 cent.
1/1000th of a cent might be useful when calculating the BOM price of your new electronics device, when you order SMD resistors by the container ;-)

A GCC COBOL status report

Posted Feb 16, 2023 15:39 UTC (Thu) by Wol (subscriber, #4433) [Link] (2 responses)

Do you round up or down?

If it's .5, which way do you go (and some places rule that you round to the nearest EVEN (or odd) number).

Okay, fixed decimal doesn't cover rounding rules, but it copes very nicely with correcting different mandatory precisions.

And don't throw significant figures into the mix! When we had the ERM, all calculations had to be done to six significant figures. THAT was fun! Not.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 27, 2023 21:49 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

> And don't throw significant figures into the mix! When we had the ERM, all calculations had to be done to six significant figures. THAT was fun! Not.

Seriously? So for amounts higher than £9,999.99, you started losing precision?! I'd have expected dp at the very least.

A GCC COBOL status report

Posted Feb 27, 2023 22:33 UTC (Mon) by Wol (subscriber, #4433) [Link]

Sorry no.

All exchange rates had to be specified to six figures eactly. Iirc, being about 4 orders of magnitude apart, Sterling to Lire and back wasn't pleasant. Mostly on the display side, not the calculation, admittedly.

And then if you are calculating random exchange rates, rounding before quoting wasn't pleasant either.

Cheers,
Wol

A GCC COBOL status report

Posted Feb 19, 2023 20:15 UTC (Sun) by ssmith32 (subscriber, #72404) [Link] (1 responses)

Stock price quotes are not to the penny. They go out to ten-thousandths of a dollar:

https://www.investopedia.com/terms/d/decimal-trading.asp

So even 1/1000 isn't good enough.

A GCC COBOL status report

Posted Feb 21, 2023 19:42 UTC (Tue) by calumapplepie (guest, #143655) [Link]

1/1000 of a *cent* is

A GCC COBOL status report

Posted Feb 28, 2023 1:38 UTC (Tue) by mrugiero (guest, #153040) [Link]

And then you need to convert currencies. 1ARS is worth U$S0.005. There are cents for ARS too and you need to be able to account for them.
I risk guessing financial institutions do deal with multiple currencies.

A GCC COBOL status report

Posted Feb 23, 2023 12:46 UTC (Thu) by mrugiero (guest, #153040) [Link]

> That will lead to poor performance relative to pure binary numeric processing.
>

It's not just performance tho. I don't think that was even what the language designers were thinking of when they went for that, but I may be wrong.
When a language makes it easier to do the right thing than it makes doing the wrong thing, you make fewer mistakes. If I need to use a library for proper decimal arithmetic, there's a (high) chance that '0.11' will slip by accident both in my code and in review. Because that's the intuitive thing to write. Now, if '0.11' is actually the right thing and you don't need to give it extra thought, you do the right thing by default, almost by accident.