Re: Update on COBOL position on IEEE decimal floating-point usage
From: Charles Stevens <charles.stevens@xxxxxxxx>
To: IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>
Subject: Update on COBOL position on IEEE decimal floating-point usage
Date: Sat, 5 Mar 2011 11:21:20 -0700
We've run into a bit of controversy in the COBOL drafting
committee on the best way to handle IEEE floating-point
formats (particularly the decimal formats) and arithmetic.
One camp wants the implementor to be free to specify any
details of an intermediate format he wants for arithmetic
operands and results (at the level of the operation)=2C
so long as the results are exactly the same as what IEEE
754 floats would prouce=2C and so long as the fullly-defined
and not-quite-so-fully-defined USER descriptions of data
items conform in the sense that their values are identical.
This applies to binary arithmetic and to decimal
arithmetic=3B the results in the former case are AS IF the
results were in binary128 format=2C and in the latter AS IF
the results were in decimal128 with the encoding choice
specified for the imlementor for the intermediae result
format=2C and for the not-quite-so-rigorously-defined data
items to match as well.
Another camp feels=2C given the fairly-rigorous definition
of the IEEE formats=2C it is more in keeping with the
direction given the COBOL committee to require that the
intermediate format SHALL BE as specified in IEEE 754 (for
binary128 when "binary arithmetic" is specified=2C and for
decimal128 with either the decimal or binary arithmetic
when "decimal arithmetic" is specified. The implementor
gets to specify which encoding is used for the intermediate
results=2C and whatever encoding he chooses there is also
used for the not-quite-so-fully-defined USER descriptions
of decimal floating-point data items=2C but in all cases
the standard would specify rigorously that an IEEE format
is used for the intermediate item=2C and the implementor
would only be free to specify which of the two encodings
were used there as well aso for the two "general"
Mike's point about asking your committee members to
speak for themselves is well taken. For indeed, as
you make their cases they are not so far apart as
you might think.
In this issue, as with the issue of decimal or binary
encoding, the actual encoding you use has little or
nothing to do with conformance to 754. The encodings
are there to have a format within which to package
the numbers when you give them to someone else. In
effect, interchange. Thus the distinctive name:
It is true that most conforming implementations use
one of the interchange formats for the 5 basic
floating-point datatypes when they are stored in
memory. It is also true that almost all conforming
implementations use something entirely idiosyncratic
to their machines when those numbers are loaded into
The only thing about the formats that is required
for conformance is that they represent exactly the
same set of data items (numbers, et al) that is
defined in 754. Then they may be called a 754
So this whole format thing (binary versus decimal
encoding as well as non-interchange formats for
internal use only) is mostly a non-issue & should
not be taking up as much of your concern as it has
Of far FAR more importance to conforming to 754 is
the issue of how those data elements are used. On
this point 754 has much to say & much which is
required of everyone who wants to conform. This
includes inconvenient things like the proper use
of NaNs & infinities as well as complete support
for all the required functions. (Clause 9 functions
like arccosine & the like are also a non-issue. All
are optional & non-conforming versions may be used
without harming your ability to conform to 754.)
But you must support add, subtract, multiply, divide,
conversions to other supported formats, the full set
of required comparisons & a few other minor functions.
And you must support them for their full set of
possible operands & results including things like NaN,
infinity, & signed zeros.
This is where the rigorous test for conformance lies.
Mostly nobody cares about the details of the formats.
. . .
What do you think? In other words=2C give me a solid
reason to believe rigorous conformance to the IEEE formats
for COBOL's arithmetic operations is not a good idea.
For I do not believe it to be true.
But, again, you know your customers better than I.
If the choice is dusty decks versus 754-2008, you
may just have to give up conformance in favor of
supporting your long time customers.
Still, the way you have described how one must
specify the use of 754 numbers in Cobol, I can't
imagine such a specification existing in a still
useful program written in the 1960s.
PS: Typing is a bit of a chore with my arm in a tight
sling. I'll do what I can=2C but response may not be
as prompt as I would like.
Letting your other members participate might help.
As might learning to be terse.
But as I have 2 reasonable good arms, I will go on
for a bit. :-)
There is an argument in favor of the camp that wants
the user to be able to specify things.
One of the recent advances that 754-2008 has over
754-1985 is we introduced a standard way of allowing
the user to specify datatypes that we will bless as
They come in two flavors: interchange types & non-
interchange types. We have further specified some
interchange formats for the former but not for the
Within broad limits (of making numerical sense) the
user is allowed to specify (1) the base (binary or
decimal) within which the arithmetic is done; (2)
the number of significand digits (in that base); &
(3) the exponent range.
Once specified, the nature of the arithmetic is
already defined (largely in clauses 3 & 5) & all
required functions must be supported for that type
as well as conversion to & from.
I mention this for 2 reasons.
First, it seems to be in keeping with the intimate
way data is characterized in Cobol. More so than
in other languages.
And, second, should you find a way to characterize
floating-point formats in this manner, it might be
the last extension of this nature that you have to
make. The 754 user defined types include an
infinite class of datatypes that covers pretty much
anything you might like to do. And all of them have
good well defined arithmetic.
As a committee that should concern itself more with
language issues & less with numerical ones, it might
end up being a wise move for the future.
Of course, you are hearing this from someone who has
spent a career concerning himself more with numerical
issues than with language ones.
I may be looking at the problem in a different way.
Well, this ends my latest friendly rant.
Take it for what its worth.