Speaking as an expert on the SQL standard, I think Dan is right.|
The SQL standard, part 1 "Framework"
subclause 220.127.116.11 "Rule evaluation order" says
"A conforming implementation is not required to perform the exact
sequence of actions defined in the General
Rules, provided its effect on SQL-data and schemas, on
host parameters and host variable, and on SQL
parameters and SQL variables is identical to the
effect of that sequence. The term effectively is used to
emphasize actions whose effect might achieved in
other ways by an implementation."
So we have already built into the SQL standard that what counts is the results
that are visible to the user, not the intermediate steps that get there.
Maybe the COBOL standard already has a similar provision.
I think it is commonly understood that standards exist to define portability
of results, while leaving implementers free to compete on the best way
to achieve those results.
On 3/5/2011 1:35 PM, Dan Zuras IEEE wrote:
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 registers. 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 latter. 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. Enjoy, Dan
Fred Zemke | SQL standards representative
Phone: +1 6505062051
Oracle is committed to developing practices and products that help protect the environment