Fear not! MOVE CORRESPONDING is alive and well! |
The issue of "native arithmetic" bears on portability. COBOL is intended to be a portable language. 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. That's been a primary design criterion throughout its life.
Yes, users are free to specify ARITHMETIC IS NATIVE, and in that mode, the implementors are gonna do whatever it is they want to do, and the users are gonna get the results the implementor provides.
In the 2002 standard, in an effort to provide more portable, and more platform-independent results, ARITHMETIC IS STANDARD was introduced. The specifications remain COBOL-specific, some of the features remain implementor-defined, and no mechanism was provided by which a user could define a numeric data item in the same form used in that mode for arithmetic operations.
With the development of IEEE 754r, the COBOL community saw an opportunity to specify a platform-independent mode of arithmetic with results defined, not by the COBOL standard, but by an independent, platform-neutral industry standard over which COBOL held no sway.
Thus, in the FCD, the implementor is encouraged to allow the user to describe data items as being any of five IEEE floating-point formats (corresponding to decimal64, decimal128, binary32, binary64, and binary128), and also encouraged to provide either or both of two modes of arithmetic, whereby the intermediate data item used for all arithmetic is decimal128 or binary128.
Because the binary encodings frequently provide inexact results for non-integer decimal representations, ARITHMETIC IS STANDARD-DECIMAL is explicitly described as preferred over ARITHMETIC IS STANDARD-BINARY. The implementor is free to provide any, all, or none of these features (as was the case for ARITHMETIC IS STANDARD in the 2002 standard).
As I recall it, the binary encoding of the IEEE decimal floating-point standards was introduced into the IEEE 754 draft well after the fundamental structure of the features in COBOL had been developed, and met with significant approval in the community. Because COBOL is fundamentally a decimal language, when the binary encoding capabilities were addd, the decision was made (rightly or wrongly) to stick with the decimal encoding and, aside from the recognition of NaNs and infinities (which are both encoding-independent), data in binary encodings would not be recognized. At the time, the authors were under the impression (without sufficient research) that it would be possible to distinguish data in the decimal encoding from that in the binary encoding by examination of the data itself; that turns out not to be the case.
As to exception handling: COBOL has had SOME form of this for a very long time -- ON SIZE ERROR in arithmetic and USE AFTER STANDARD ERROR ON <file-name>, for example. Even if the exception is fatal, this phrase on an arithmetic statement allows the user to account for the possibility and compensate programmatically for it rather than simply having the program crash.
In the 2002 standard, this capability was enhanced by the addition of a range of specific exception conditions and the ability to specify exception procedures associated with each. If an exception condition occurs, the associated exception procedure is executed. The user has the choice of enabling or disabling the detection of exception conditions through this mechanism. The focus on further development of exception handling has been through this exception-handling feature, rather than on enhancing the "old" phrases, though the old mechanisms still exist and function.
I believe all the relevant IEEE exception conditions are accounted for in the FCD by corresponding COBOL exception conditions. There are some exception conditions that the implementor would need to provide for explicitly.
Let's take the NaN case in arithmetic operations as an example. If nothing else, IF the user has specified that the testing for the EC-DATA-NOT-FINITE exception is enabled (not the default), then the implementor would need to verify that the result passes the IEEE "isFinite" test, and if it doesn't, raise the exception.
For the infinities in arithmetic operations, COBOL relies on IEEE 754 for addition, subtraction, multiplication and division, but not for squareRoot or remainder, and doesn't address fusedMultiplyAdd at all. For the IEEE-provided operations supported by COBOL, an operation with an infinite operand either produces an infinity result (valid in IEEE), or a quietNaN signaling an invalid operation. NEITHER of these would pass the "isFinite" test, and if the COBOL EC-DATA-NOT-FINITE exception was enabled, it should be raised.
All of this can be circumvented by the user by performing IF ... NUMERIC tests against the operands before using them in arithmetic expressions.
And in general, if the user has elected NOT to check for a specific error conditions, and has NOT specified an error-handling phrase (ON SIZE ERROR, for example), and one of these exception conditions would have been raised otherwise, the implementor gets to decide whether or not to terminate the run unit, and if not, what the results look like.
Date: Wed, 23 Feb 2011 10:50:32 -0700
Subject: Re: Two technical questions on IEEE Std 754-2008
CC: charles.stevens@xxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx
On Wed, Feb 23, 2011 at 9:47 AM, Dan Zuras IEEE <forieee@xxxxxxxxxxxxxx> wrote:
It has been so long since I've coded in Cobol that my favorite flavor of MOVE (corresponding) appears to be gone.
But the question of defaults, etc seems to me to be most germane to "native". If a COBOL programmer wants the maximal conformance to IEEE arithmetic, on an IEEE system seems to me that until there is an IEEE computational type, native is where an implementor should lavish attention on doing the best job possible on providing full IEEE conformance.
For the newer types, I think that the intent of COBOL (such as I recall it from my younger days) halting on exceptions IS appropriate rather than the usual IEEE mode of operation.
303 997 2749