We can't tell vendors that the "native arithmetic" they've been using for fifty years has to be CHANGED to conform to IEEE Std 754-2008. That raises SERIOUS compatibillity problems with existing programs. Just can't do that. "Native arithmetic" for each platform is expected to exist, and in that mode, the implementor does pretty much whatever he feels appropriate to do for his users in terms of arithmetic results, capacities, etc. |
What we CAN do, and HAVE done, is suggest ALTERNATIVE modes of arithmetic that the user can specify (presuming the implementor has chosen to allow it) that DOES map, with few exceptions, to IEEE 754. One of these new modes specifies that all operands to arithmetic operations, and all results, shall be in binary128 interchange format. The other new mode specifies that those operands, and those results, are in deciml128 interchange format using the decimal encoding. We have also suggested additional clauses that support the declaration of data items in IEEE binary32, binary64, and binary128 interchange formats, and of data items in decimal64 and decimal128 interchange formats using the decimal encoding.
The results of using the content of an item described with a COBOL-supported decimal interchange format in the decimal encoding are undefined if the contents of that item are encoded in binary.
We can do nothing but encourage implementors to provide support for these alternative modes of arithmetic, and for the associated data description clauses appropriate to them.
We provide what we believe are appopriate rules in support of that effort. We DO NOT require an implementor to provide them in order to be compliant with the COBOL FCD. They are what is termed "processor-dependent" features of the standard -- predicated on the capabilities of the hardware, the support software, the economic demand on the implementor for the feature, and even the implementor's emotional attitude toward the whole subject. They can provide it, or they may choose not to, for whatever reason.
I would be DELIGHTED if one or more implementors decided to make their default mode ARITHMETIC IS STANDARD-DECIMAL, and required existing programs to be changed to avoid unex[ected results to specify ARITHMETIC IS NATIVE. That choice, however, is between the implementors of the COBOL standard and their user bases.
We can also hope that users in environments that DO support the new arithmetic modes and USAGE clauses move toward using them to protect their investments in their programs, so that they are more usable on a variety of platforms in the future. If the users don't want to do that, that's their business. If the implentors choose not to support these (processor-dependent) new features, that's between them and their users. We might even at some point -- NOT in this revision -- make them mandatory rather than "processor-dependent" features. Bit bottom line: we try really hard to avoid pulling the rug out from under existing users, and we try really hard not to force imlementors to do so.
As a side note: it's been argued that IEEE arithmetic is the same regardless of the encoding. Offhand, I don't see anything that requires that decimal-format operands to IEEE arithmetic operations be in the same encoding, or that the result of the operation is in that same encoding. It seems to me that the result of adding a decimal-encoded decimal128 item to a binary-encoded decimal128 item will NOT be the same as it would if both were encoded in decimal in the first place. The results are (almost?) always valid numeric values; they're just wrong if the presumption is that the operands and the result are all in the same encoding. This is the same dilemma COBOL faces if the presumption is that the data in IEEE decimal formats is encoded in decimal; the difference is that COBOL explicitly states that only decimal is permitted to begin with.
Date: Thu, 24 Feb 2011 09:31:35 -0700
Subject: Re: Two technical questions on IEEE Std 754-2008
CC: forieee@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx
" The direction is to have a given COBOL program not only run on, but produce the same results on, any machine that supports the language"
I fear that isn't actually practical (other than via approaches like Apple's old SANE) for floating point.
I appreciate your schedule problem, and also the desire to do "the right thing". But given the schedule, I don't think it's going to be possible to do a good job on "right" so I repeat my suggestion... for this release, map full IEEE conformance to "native" (doubtless vendors will have to have a external to Cobol method to pick old native or new native) and pretty much keep what you have from 2002.
Work on doing better in a future revision or technical report.
Doing something in haste in a Standard almost always creates more problems than it solves, at least from my X3J3/J3/WG5 (Fortran) experience.