... and there's still another point to be made here. |
There's some sentiment that implementations would be likely to make "ARITHMETIC IS NATIVE" (the default) equivalent to either "ARITHMETIC IS STANDARD-DECIMAL-B" or "ARITHMETIC IS STANDARD-DECIMAL-D", and might be reluctant to provide any other form of arithmetic (and that's OK by the standard).
Let's also assume that this class of implementors has provided support for all four IEEE decimal floating-point formats described earlier, and that a program that is running just fine on the first implementation makes use of any (or all) of the IEEE formats in its data description.
Now, let's assume there's a THIRD implementation that doesn't provide support for EITHER of the IEEE modes of arithmetic, but does support the declaration of IEEE decimal floating-point items and their conversion into intermediate form as operands. "ARITHMETIC IS NATIVE" in that environment, either explicitly stated or implied by default, is NOT an IEEE mode, and an IEEE mode in the ARITHMETIC clause would not be recognized.
A program that explicitly or by default specifies ARITHMETIC IS NATIVE will run and produce the same results in the first two implementations. It would probably compile and run on the third, but not necessarily produce the same (or even meaningful) results.
A program that explicitly specifies an unsupported ARITHMETIC mode will get "flagged" at compile time in the second and third environments because such enviroments don't support the mode. Supplying the mode of arithmetic in the program helps ensure that the programs ARE portable, and that incompatibilities between implementations are detected EARLY in any conversion process from one platform to another. The fundamental principle here is that with ARITHMETIC IS NATIVE you get what you get, and that's entirely defined by the implementor on the particular platform.
For that reason, my RECOMMENDATION to implementors that want an IEEE mode as native is to allow both NATIVE and STANDARD-DECIMAL-B (or ...-D) in the ARITHMETIC clause, documenting them as synonymous to NATIVE. And my RECOMMENDATION to users in such environments would be to specify EXPLICITLY the specific mode of arithmetic the program is using successfully so that the user's expectations are made clear in the program itself.
If the user has specified the exact mode, and attempts to compile the program on an incompatible platform, they'll find out real quick that their expectations aren't going to be met. If they don't specify the mode explicitly, they may not find out until they get the wrong answers, and they mightn't even find out that the answers are wrong.
But the draft standard with my proposal incorporated wouldn't make either of these recommendations a requirement.
To: hack@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx
Subject: RE: Two technical questions on IEEE Std 754-2008
Date: Mon, 28 Feb 2011 00:26:52 -0700
There's another advantage to this approach, Michel. Let's suppose an application runs just fine on a BID-native machine, and let's also suppose that the end user has a bunch of data on disk in BID encoding. Let's further suppose that, for whatever reason, the user decides to migrate to a DPD machine (exact same thing applies in reverse(.
Assuming that each implementation supports BOTH sets of decimal USAGE clauses, assuming that that support includes the ability to convert from one encoding to another (as specified in IEEE): EVEN IF the new platform supports ONLY the ARITHMETIC phrase most suitable to that machine (STANDARD-DECIMAL-B or STANDARD-DECIMAL-D), THEORETICALLY, the ONLY change the end user would have to make to the program would be to change the ARITHMETIC clause.
Assuming the "old" preference was decimal encoding and the "new" is binary, and the ARITHMETIC clause WAS changed to reflect the "new", anytime an IEEE BID float was encountered as an operand, standard COBOL would require that the implementation must run it through the appropriate conversion functions to get it into the proper form for computation.
That means there's no REQUIREMENT for the user to convert his archive DATA unless the user finds the performance hit of the (required) conversions from BID to DPD, each time a BID item is encountered, onerous. Processor time is expensive, but preservation of the current form of data might be far more valuable to the user. The standard can't make that determination, In my view, neither should the implementor (by NOT providing data descriptions for the "opposite" encoding).
So, for my record example below, let's assume that all the FLOAT-whatever operands are FLOAT-DECIMAL-B items of one size or another. The record is legible and the operands are handled correctly, on a machine that has is running standard-decimal-d arithmetic, just as they did with standard-decimal-b arithmetic. Slower, probably, but correctly.
> Date: Sun, 27 Feb 2011 11:11:43 -0500
> To: stds-754@xxxxxxxxxxxxxxxxx
> From: hack@xxxxxxxxxxxxxx
> Subject: RE: Two technical questions on IEEE Std 754-2008
> (And also: RE: A general comment on COBOL "modes of arithmetic")
> I'd like to thank Chuck for his generous time in reminding me how COBOL
> works. COBOL grew up in an area where machines and data representations
> varied much more widely than they do today, and I have to agree that in
> this context Endianness is just a minor glitch. It just happens to be
> the major remaining representation issue today, when nearly all machines
> are byte-oriented with power-of-two-sized formats.
> What really sums it up is the following:
> > Endianness as I see it is generic to the platforms across data types.
> > and unless somebody shows that endianness affects the IEEE floats in
> > some way that's different from how it affects everything else in data,
> > it's not a COBOL standardization issue at this time.
> I've essentially said the same thing when I wrote, regarding 745-2008 3.2:
> >> ... (Perhaps we should have mentioned it, to make sure everybody
> >> understood that BID vs DPD is almost at the same level as Endianness. It
> >> is in practice not quite at the same level because all sorts of mechanisms
> >> are already in place to deal generically with Endianness, whereas the DFP
> >> encoding issue is new and rides on top of the Endianness distinction.)
> What Chuck's approach permits, and my suggestion doesn't, is the following:
> > 01 EMPLOYEE-RECORD.
> > 03 NAME.
> > 05 FIRST-NAME PIC X(20).
> > 05 MIDDLE-INITIAL PIC X.
> > 05 LAST-NAME PIC X(20).
> > 03 SSN PIC 9(9).
> > 03 HOURLY-WAGE USAGE FLOAT-BINARY-7.
> > 03 HOURLY-ADJUSTMENTS USAGE FLOAT-DECIMAL-D-16.
> > 03 HOURS-WORKED-THIS-YEAR USAGE FLOAT-DECIMAL-B-16.
> > ... etc., still 50 bytes.
> In other words, mixed encodings in the same record.
> I suppose it's conceivable that the programmer did this knowing that the
> two fields were going to be forwarded to different processing programs,
> one running on BID-friendly hardware and the other on DPD-friendly
> hardware. This is something languages like C would not be able to do.
> I still consider it as the equivalent of having some fields explictly
> declared Big-Endian and others Little-Endian in the same record -- but
> as we all agree this is NOT what COBOL is intended to deal with.
> Another advantage of Chuck's way is that he (in his standardization work)
> took on the job of dealing with this new distinction, taking the burden
> away from implementers. My way would require implementers to modify the
> way they handle record conversions generically by dealing with BID/DPD as
> well. My point was simply that if there is a way to transmit records such
> as the above across Endianness differences, that could have been augmented
> to deal with BID/DPD as well. I would have been extra work for somebody
> other than Chuck.
> P.S. I hope we reached a satisfactory conclusion to this long excursion
> prompted by a simple question!
> ---Sent: 2011-02-27 16:58:34 UTC