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

*To*: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>*Subject*: Implementor support for the binary interchange formats*From*: Michel Hack <hack@xxxxxxxxxxxxxx>*Date*: Mon, 28 Feb 2011 13:22:20 -0500*List-help*: <http://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

Since binary128 supports 34-bit integers EXACTLY, there should be zero precision loss for traditional COBOL usage of scaled decimal (e.g. by handling currency in micropennies). This applies even when legal requirements specify a given decimal precision, e.g. IRS requirements to round fractions to 4 digits after the decimal point, or European Union currency conversion rules. Surely COBOL has been handling this well for years... This reminds me of a question I asked earlier: would COBOL exploit the fact that DFP permits decimal fixed-point arithmetic to be emulated without the need to remember the scale separately? My guess was NO, given the statement that COBOL would assume all floating-point (including decimal) to be normal, and the fact that this would inhibit easy switching between arithmetics. But, as William Klein pointed out:

1) Arithmetic mode PRIMARILY deals with "intermediate results".

So operations like (7 / 4 ) * 4 could be affected. Michel. ---Sent: 2011-02-28 18:35:14 UTC

**Follow-Ups**:**RE: Implementor support for the binary interchange formats***From:*Charles Stevens

- Prev by Date:
**RE: Implementor support for the binary interchange formats** - Next by Date:
**RE: Two technical questions on IEEE Std 754-2008** - Previous by thread:
**RE: Implementor support for the binary interchange formats** - Next by thread:
**RE: Implementor support for the binary interchange formats** - Index(es):