Re: Two technical questions on IEEE Std 754-2008
From: "William M Klein" <wmklein@xxxxxxxxxxxxx>
To: "'Dan Zuras IEEE'" <forieee@xxxxxxxxxxxxxx>
Cc: "'IEEE 754'" <stds-754@xxxxxxxxxxxxxxxxx>,
"'Charles Stevens'" <charles.stevens@xxxxxxxx>
Subject: RE: Two technical questions on IEEE Std 754-2008
Date: Thu, 24 Feb 2011 17:48:00 -0600
That you don't seem to be interested in using both
encodings wastes that latter time. That you don't
seem to be willing to support decimal even to the
point of changing the fundamentals of the arithmetic
WRT NaNs & infinities wastes the rest.
-----End Original Message-----
I am curious, although COBOL is no longer "strictly" limited to "business"
applications (cf. the "B" in COBOL), this is certainly our historical (and
even today MAJOR) usage.
Can you give me some examples of how/or why a business application might
want to do "numeric" operations on a Nan or Infinity?
. . .
However, I am quite serious in wanting to know what FEATURES you think we
are missing that our users will/would want.
P.S. My personal guess is that if any of these features ARE of significant
interest to COBOL users, that implementors will provide them as extensions -
until the next revision of the Standard. It is only those features of
minimal or no use that tend NOT to get implemented - Especially if the
environments provide either software or hardware support for "fully
conforming" 754 support.
I gave an example of financial forecasting in
my note of Wed, 23 Feb 2011 08:47:45 PST.
I will quote it again if you like but it comes
down to an issue choosing among probablities
that are wildly different & can get very small.
One compares the ratios (or differences of the
logs) & chooses one from another. These ratios
can get very large (up to & including overflowing
to infinity). In which case the ratio is ignored
& the larger of the two probablities is chosen.
Or they can get very small (down to & including
zero). In which case the denominator is chosen.
The latter causes no problems for anyone. The
former also causes no problems in systems that
handle infinity as any other number.
For financial calculations (including forecasting)
the handling of NaNs is less interesting. Indeed,
they show up in Monte Carlo models only when the
infinities are miss handled & one tries something
like inf - inf. So, in this case, the way Cobol
handles NaNs is quite similar to how 754 handles
them when the invalid attribute is enabled & some
sort of fatal (or diagnostic) trap handler is
I suggested this to Charles as a reasonable way
to go that only changes the defaults for 754 not
the arithmetic itself. It does not seem to be in
keeping with what you have in mind.
Aside from financial forecasting, I agree that
the use of NaNs & infinities is largely not
meaningful for any number that has units attached
to it (femtopfennigs, footpoundals/fortnight,
shekels/month, that sort of thing). If Cobol
knows that units are attached to a number then
interrupting the flow of execution to deal with
infinities is reasonable.
Again, I suggested to Charles that this behavior
is quite similar to alternate exception behavior
for 754 when the overflow attribute is enabled.
As I suspect Cobol already chokes on a divide by
zero, this could be handled by alternate exception
handling for the divideByZero attribute.
All of these things are described in clause 8 of
the current 754 document.
Should Cobol choose to use these mechanisms to
'wedge' 754 into the Cobol philosophy, my personal
opinion is that it would be a much cleaner way to
go than altering the fundamental behavior of the
arithmetic. It would still mean that Cobol fails
to conform. But I think it would be much more
acceptable to everyone as only a slight & (given
Cobol's history) understandable variance.
That was my intent anyway.
Perhaps it is insufficient to do the job.
As for FEATURES with a capital FEATURE, I am
entirely unqualified to know how Cobol's behavior
affects its customers either for good or for ill.
I'll leave that for others to judge. I am merely
trying to preserve that which is best in the
arithmetic without stepping to much on the old
I don't think I'm doing very well.