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

*To*: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>*Subject*: IEEE rounding and COBOL*From*: Michel Hack <hack@xxxxxxxxxxxxxx>*Date*: Sun, 22 Jan 2012 21:53:43 -0500*List-help*: <https://listserv.ieee.org/cgi-bin/wa?LIST=STDS-754>, <mailto:LISTSERV@LISTSERV.IEEE.ORG?body=INFO%20STDS-754>*List-owner*: <mailto:STDS-754-request@LISTSERV.IEEE.ORG>*List-subscribe*: <mailto:STDS-754-subscribe-request@LISTSERV.IEEE.ORG>*List-unsubscribe*: <mailto:STDS-754-unsubscribe-request@LISTSERV.IEEE.ORG>*Sender*: stds-754@xxxxxxxx

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

**Follow-Ups**:**RE: IEEE rounding and COBOL***From:*Charles Stevens

**RE: IEEE rounding and COBOL***From:*Charles Stevens

- Prev by Date:
**Re: round32 ( round64 ( X ) ) ?= round32 ( X )** - Next by Date:
**Test vectors for decimal floating point** - Previous by thread:
**Re: round32 ( round64 ( X ) ) ?= round32 ( X )** - Next by thread:
**RE: IEEE rounding and COBOL** - Index(es):