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

IEEE rounding and COBOL



On Tue, 29 Mar 2011 10:11:05 -0600 Chuck Stevens wrote:

For fixed-point arithmetic, COBOL has always operated under what I
will call the "window of significance" principle.  For example, if the
intermediate result of an operation is +99990000 (= +9.9990000...e+7),
and the receiving field is described as having five decimal digits with
the implied decimal point on the left (PICTURE V9999 USAGE DISPLAY),
the result is ZERO, regardless of any rounding specification, ...

I'm a bit confused by the example value cited.  It seems to me that ANY
exact integer would be displayed as .0000 because the format explicitly
beheads the integral part.

As I see it, for strict conformance to IEEE rules, the overflow exception
would be raised for all rounding modes.

Only if COBOL claims that this PICTURE format corresponds to one of the
conversions described by Clause 5.12.2 of 754-2008.  Nothing prevents COBOL
from having conversions that play by their own rules.  What 754 *does*
require is that there be *some* operation that converts floating-point
datums (as we call them, deliberately) to decimal character strings that
obey the 5.12.2 rules.  If COBOL has a format that allows an exponent to
be displayed this should not be a problem -- especially if those formats
are allowed to raise exceptions (which are indeed permitted to be fatal).

But it seems to me that at least some of the IEEE rounding-direction
attributes would produce a value of +(0.)9999.

Not in this case, as this is effectively an EXACT overflow, possible if
overflow is trapped.  If a trap handler other than termination is available
the beheaded part (or the original source value) should be made available
to it.  Rounding applies to lost low-order bits or digits, not to beheading.

Similarly, when the intermediate result is like +0.0099 (= +9.9e-4) and
the receiving field is a four-digit integer (PIC 9999 USAGE DISPLAY),
the result historically expected from COBOL is ZERO, with no exception
condition raised, and regardless of the presence of the ROUNDED phrase
(or any specification of modes of rounding).

This case is different.  Here rounding is applied, and if directed rounding
away from zero is in effect (and that PICTURE format claims to be one that
follows 754-2008), then the result would have to be 0001.

Directed rounding is easy to understand: the result must be no greater than
(or no less than) the exact value, and be the nearest with that property.

Michel.
---Sent: 2012-01-23 03:19:38 UTC


754 | revision | FAQ | references | list archive