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

*To*: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>*Subject*: RE: Two technical questions on IEEE Std 754-2008*From*: Michel Hack <hack@xxxxxxxxxxxxxx>*Date*: Wed, 23 Feb 2011 13:53:52 -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

Chuck Stevens wrote:

At some point we could consider adding something like ARITHMETIC IS IEEE-754-DECIMAL-ENCODING and ARITHMETIC IS IEEE-754-BINARY-ENCODING, with the specification that EVERYTHING the standard does in terms of data manipulation (including infinities) conforms to IEEE Std 754-2008 (or its successor) with no further details in the COBOL standard.

This is precisely what I argued AGAINST in my earlier note. The ARITHMETIC is independent of the encoding. ARITHMETIC IS STANDARD-DECIMAL should be enough. It may be useful to have an enquiry ("predicate", as opposed to a directive or environmental constraint) to find out what the encoding is, but it seems pretty irrelevant from a COBOL point of view. If COBOL can stomach the IEEE Infinity and NaN rules, ARITHMETIC IS IEEE-754 would be an appropriate declaration, in addition to the BINARY/DECIMAL distinction for the arithmetic (NOT for the encoding). What IS relevant however is the interchange format used, i.e. when records are imported or exported. If at that level there is a single type, e.g. FLOAT-DECIMAL-34, then the encoding in the external medium (file, message, DB entry etc.) should be fixed. Given COBOL's decimal heritage it would be fitting to pick DPD for that (full disclosure: I work for IBM) -- but at least the cost of in/out conversion for BID-based platforms would be limited to import/export functions, and would not impact processing. This (import/export) is the context where it is most annoying that we ended up with two standard encodings. COBOL might be the first language to take this issue seriously... Michel. ---Sent: 2011-02-23 19:09:36 UTC

- Prev by Date:
**RE: Two technical questions on IEEE Std 754-2008** - Next by Date:
**RE: Two technical questions on IEEE Std 754-2008** - Previous by thread:
**RE: Two technical questions on IEEE Std 754-2008** - Next by thread:
**Re: FW: Two technical questions on IEEE Std 754-2008** - Index(es):