Much history snipped. |
> Hmm. I'm not quite sure what you mean here
> but you WILL have to provide for the values
> +infinity & -infinity if you want to conform
> to 754-2008.
> Recognising binary encoding is not necessary.
Actually, we are not, strictly speaking, claiming "conformance" to 754-2008, we are making reference to it for the five formats we support in data, the two formats we support as "standard intermediate data items" in arithmetic and for numeric function return values, and for the simple arithmetic operations. For this revision, we are sticking with the existing definitions for the more complex arithmetic (exponentiation and arithmetic functions like LOG, SIN, etc.) to avoid conflict with existing implementations and the history of COBOL.
We do recognize infinities and NaN's, just not during arithmetic. We recognize them enough to cause an exception condition at run time if one tries. For either one, where both arguments are, say, decimal128,
MOVE AN-INFINITY TO AN-ITEM
works just fine, but
COMPUTE AN-ITEM = AN-INFINITY
results in a fatal run-time exception condition (for which the tools exist in the language to assist in recovery) . The first is a bitwise transfer, the second is treated as arithmetic.
Class (numeric, infinity, NaN) tests are all provided for, as well as the extraction of signs from infinity. And, by the way, we have no interest in the payload of NaN's.
One of our primary goals is maintaining philosophical continuity with 50+ years of COBOL history, and the concept of infinity, and the concept of dealing with infinity arithmetically, are foreign to the language. Maybe in a future revision we can provide yet another mode of arithmetic that is FULLY conformant to IEEE 754-2008 (or its successors), but as it is in the FCD, we already support FOUR modes of arithmetic:
NATIVE (the original): the implementor does whatever he wants whenever he wants, and gives whatever answers he wants
STANDARD (2002): Arithmetic is performed with all operands and the result in a single form; unfortunately, the ability to specify a data item in that form wasn't included
STANDARD-DECIMAL (FCD): Arithmetic is performed using decimal128, content is always norma from the view of the program
STANDARD-BINARY (FCD): Arithmetic is performed using binary128, content is always normal from the view of the program
In the FCD, we also provide the ability to declare user data items in forms defined as equivalent to binary32, binary64, binary128, decimal64 and decimal128. For the "standard intermediate data item" used when standard arithmetic was in effect, there wasn't a corresponding way to declare a data item as being exactly in that form. That's one of the strengths of the revisions to the 2002 standard.
One of the reasons we decided to incorporate features (again, not claim conformance with) IEEE 754 is that, as far as I know for the first time, an industry-standard specification outside of COBOL provided explicit support for 31-decimal-digit numeric values that COBOL requires.
> And nothing bad should happen should you
> encounter one.
Calculations involving infinities are much more meaningful in the scientific world than they are in the business world. In COBOL we need to define the EXACT answer as to what happens when you add 1 to +infinity, and why that's the RIGHT answer from a business (generally speaking, financial) standpoint. While people dealing primarily with dollars and cents do expect to do accurate arithmetic on VERY large values, they do not expect to do accurate arithmetic on INFINITELY large values.
> As you have observed, this is not possible by
> looking at the numbers themselves. The two
> encodings overlap in their bit values with
> each representing different numbers & each
> rejecting different bit patterns as senseless.
> In order to do what you want sensibly you will
> need the AmIBinary?() or AmIDecimal?() predicates
> I mentioned before.
We say throughout the draft that we only deal with the decimal encodings, in no uncertain terms. From the user's, and the implementor's, view, we don't "know about" binary encodings. If a user should manage to put a binary-encoded decimal into a decimal128 item in, say, a file, or passed into a program across a wire, the results of treating the content as a numeric value are not currently specified. What I'm proposing is that we make the algebraic value in such a case explicitly undefined and leave it at that.
Further capabilities, like re-encoding functions, parallel data forms to the currently-proopsed decimal formats but using binary encoding, and even yet another form of arithmetic using the decimal128 format in the binary encoding, can be specified in a future revision, but for now, the appropriate response to binary-encoded data in decimal-encoded fields is naughty-naughty, don't do that or you'll get bit. It's too late in the drafting process to consider crafting specifications for the additional features required in the current revision. We are hoping we'll get final approval for publication in May of this year, and something this major would require us to go through at least one more ballot cycle.
Moreover, even if we did all this, there's no way for a COBOL program to tell which encoding "somebody out there" used to produce a numeric value when they sent it to us as a decimal128 item, so the dragons are still out there.
> While you could support the reencoding operation
> in software on your decimal encoded machine, you
> will find that the Intel folks intend to support
> binary encoding in hardware. If they also
> support conversion to decimal in hardware, you
> may find it best to ask the sending machine to
> convert its data to decimal before it gets to
> you. But it works either way.
The Intel plan is nice to know; either way, the information will have to get into decimal encoding before it gets to COBOL (in a fashion invisible to the user) whether that's directly supported in hardware or software. COBOL doesn't care. Does that mean that COBOL programs might run less efficiently on Intel than one might hope they would? Yeah, well ...
> Here there be dragons & undetected bugs will
> bash your program on the rocks.
Yes. I understand.
> The only winning strategy is not to play.
> Don't allow such bit patterns onto your
> machine until they are both recognised &
We can't prevent users from puttng binary-encoded information into a data item that is documented as requiring the decimal encoding. And we don't make specific reference in the FCD to the individual functions available in 754-2008.
> The IsDecimalEncoding() predicate is the
I'm unclear as to how to require the inclusion of a "predicate" to a 128-bit value coming in from "out there somewhere", say, as a field in a record without requiring the addition of something to the storage requirements, and that doesn't seem to me to be practical. We don't know where the data is coming from, and we have no control over how the sender encoded it, or whether he's willing to inform us as to which encoding he used in the process.
Maybe I don't understand what is meant here by the term "predicate".
I really appreciate all your help here, Dan, and I think we're moving in the right direction, given the time limits we face and the current status of our FCD.