[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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:
        interchange formats.

        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
        compatible representation.

        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
        already done.

        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.

        I cannot.

        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.

   -Chuck Stevens

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
        754 conforming.

        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.



754 | revision | FAQ | references | list archive