3 ms·
COBOL uses fixed-point decimal arithmetic, not binary floating-point. You'd declare these variables as PIC V99 and then get a nice neat .10×.10=.01 (or as PIC 9
by wolfgang42 9y ago
COBOL uses fixed-point decimal arithmetic, not binary floating-point. You'd declare these variables as PIC V99 and then get a nice neat .10×.10=.01 (or as PIC 99V999 and get 00.100×00.100=00.010, or whatever). This is because it's a Business-Oriented Language, and businesses don't want floating point rounding errors in their finances.
Incidentally, this was actually faster than binary floating-point on the machines for which COBOL was designed, which used EBCDIC and had special circuitry for arithmetic on binary-coded-decimal numbers. You could operate directly on the decimal representation without having to do any conversion for I/O.
- amelius 9y agoIntel x86 can also work natively with BCD numbers. https://en.wikipedia.org/wiki/Intel_BCD_opcode https://en.wikipedia.org/wiki/Intel_BCD_opcode
- bashook 9y agoVery cool. Unfortunately it's no longer supported in Long mode (x86-64). :-(
- upofadown 9y agoI used to do a lot of BCD in embedded POS stuff. No one will miss it. You can do anything you can do in BCD with regular integers if you have any understanding of integer arithmetic. Yeah, it is going to take a little more time to convert to/from decimal digits you can display/input but processors these days have fast integer division so that doesn't matter. A current issue is that a lot of programmers are bad at integer arithmetic. It isn't really taught in school.
- rst 9y agoNit: the COBOL spec dates to 1960; EBCDIC came later, ~1963. In 1960, character codes were specific to the manufacturer, and sometimes to the machine. IBM had a 6-bit BCD code that was mostly consistent across its line, but Univac had its own which was quite different.