Thanks, Dan. My point from an IEEE view is that I would rather have all the formats *that COBOL deals with* be, as rigorously compliant to IEEE as possible. I don't care whether the implementor has to put them in a different form regardless of what mechanism is used actually to PERFORM the arithmetic -- whether it's to put the operands on the stack, put 'em in arithmetic registers, or have 'em enscribed on parchment scrolls in Braille and shipped via the next pilgrimage to a monastery full of discalced Cistercians in eastern Poland the blind monks to do the math using abacuses. Having the possibility of "scroll format" for a given implementation strikes me as a little too loose. |
Given that there DO seem to be implementations that directly support -- or come close to directly supporting -- one or the other of the three IEEE 128-bit formats in math, I'd rather see implementations go THAT direction, and use whatever form of IEEE format suits them best for arithmetic, despite the fact that it might not perform QUITE as efficiently as a "do your own thang" format, for the sake of compatibility and portability. There are three legitimate IEEE formats for the standard intermediate results, and the cost of using one of those three should not be all that onerous in implementations that support IEEE arithmetic to begin with.
Under current conventions, the implementor IS free to use whatver form the implementor wants to use for the arithmetic itself -- as an implementor-defined extension -- and also to define the "not-quite-so-rigorous FLOAT-DECIMAL-16 and FLOAT-DECIMAL-34 phrases of the USAGE clause map to the "what-EVER!" format the implementor wants to use -- also as an implementor-defined extension. I'd rather keep the STANDARD intermediate operands and formats strictly those defined by the standard. What the implementor has to do to get the data FROM a standard form INTO whatever he ACTUALLY USES for the math instructions for his "best fit" shouldn't be the STANDARD's business.
Note that I DO STRONGLY recommend that the seven "rigorously-defined" IEEE floats be strictly conforming to IEEE 754. I think it makes more sense for what the COBOL "side" does with math to be in a "strict" form for maximum portabiity than in "what-EVER!" form, particularly given the express ability to declare a data item in exactly the format of a SDIDI. the lack of which was a significant drawback to 2002 standard COBOL.
For that reason, I believe the ONLY question the end user should have to ask about data in the two remaining floats is which decimal encoding they use, not the sort of stylus they have to use to encode the parchment scrolls to go with a pilgrim on his next trip to Poland. That sholdn't have to be the COBOL standard's business, in my view, and by extension, beyond the single encoding variation within IEEE formats, shouldn't have to be the user's either.
> To: charles.stevens@xxxxxxxx
> CC: stds-754@xxxxxxxxxxxxxxxxx; forieee@xxxxxxxxxxxxxx
> From: forieee@xxxxxxxxxxxxxx
> Subject: Re: Update on COBOL position on IEEE decimal floating-point usage
> Date: Sat, 5 Mar 2011 13:35:33 -0800
> > 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"
> > FLOAT-DECIMAL formats.
> 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.