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

Re: Update on COBOL position on IEEE decimal floating-point usage



Speaking as an expert on the SQL standard, I think Dan is right.
The SQL standard, part 1 "Framework"
subclause 6.3.3.3 "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.

Fred

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

--
Oracle
Fred Zemke | SQL standards representative
Phone: +1 6505062051

Green
          Oracle Oracle is committed to developing practices and products that help protect the environment

754 | revision | FAQ | references | list archive