> Since binary128 supports 34-bit integers EXACTLY, there should be zero
> precision loss for traditional COBOL usage of scaled decimal (e.g. by
> handling currency in micropennies).
ummm ... binary128 actuallly supports 34-digit decimal INTEGERS exactly. And, yes, COBOL has been handling this well for years.
Even using the "new" standard modes of arithmetic, COBOL would continue to treat such fixed-point operands as integers and apply the scaling separately.
The 2002 standard added floating-point data items (USAGE FLOAT-SHORT, FLOAT-LONG, and FLOAT-EXTENDED, with the specifications left to the implementor) to provide a "standardized" equivalent to what implementors had had for years (e.g., USAGE REAL and USAGE DOUBLE in Burroughs B6700 COBOL68). They also provided for floating-point numeric literals, as well as floating-point edited items that include the signed exponent.
In the 2002 standard, if "native arithemtic" is in effect, what you get on any arithmetic operation is what the implementor says you're gonna get. Under "standard arithmetic", though, the form in which all operands to arithmetic, and all results, are put is n "abstract, signed, normalized decimal floating-point item. The format of this item is such that it can contain a normalized significand of 32 decimal digits", and the overall magnitude range is specified as being from (10**(-999)) to (10**1000 - 10**968) inclusive.
The precedent for floating-point handling is already in the published standard. What we're doing here in the draft is building on that precedent based on an external industry standard rather than on further COBOL extractions. In fact, the draft marks "arithmetic is standard" as an obsolete feature, to be removed in the NEXT revision, even though it's only been in a single edition of the standard so far.
Yes, historically, *standard* COBOL has dealt only in fixed-point numerics. Many (and probably most) had floating-point extensions, and in 2002 *standard* COBOL began dealing in floating-point numerics in response to that market force.
> But, as William Klein pointed out:
> > 1) Arithmetic mode PRIMARILY deals with "intermediate results".
> So operations like (7 / 4 ) * 4 could be affected.
Yes, they could, in NATIVE arithmetic as compared to STANDARD arithmetic. And it's precisely to avoid answers like "1" that "standard arithmetic" was introduced.
In 2002 COBOL STANDARD arithmetic, this would be something along these lines.
a) Store the decimal numeric value 7 in decimal floating-point temporary #1 (+7.00000000000000000000000000000000e0)
b) Store the decimal numeric value 4 in decimal floating-point temporary #2 (+4.00000000000000000000000000000000e0)
c) Divide temporary #1 by temporary #2, storing the result in temporary #1 (+1.75000000000000000000000000000000e0)
d) Store the decimal numeric value 4 in temporary #2 (+4.00000000000000000000000000000000e0),
e) Multiply temporary #1 by temporary #2, storing the result in temporary #1 (+7.00000000000000000000000000000000e0).
f) Convert the value in temporary #1 into whatever form is specified by the receiving field.
Floating-point isn't foreign to COBOL. I grant that it was foreign to STANDARD COBOL until the '02 standard, but it ain't no more.
Note also that the value in EVERY SINGLE fixed-point numeric data item can be represented EXACTLY as an integer OR as a fixed-point value in a decimal128 item (of either encoding). Every allowed decimal INTEGER can be likewise stored in a binary128 item; things begin to go awry with precision loss when poers-of-two scale factors are applied.