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

RE: Two technical questions on IEEE Std 754-2008



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


754 | revision | FAQ | references | list archive