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

*To*: stds-754 <stds-754@xxxxxxxxxxxxxxxxx>*Subject*: A general comment on COBOL "modes of arithmetic"*From*: Michel Hack <hack@xxxxxxxxxxxxxx>*Date*: Sat, 26 Feb 2011 20:34:30 -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

Frankly, I'm a bit confused by these modes of "arithmetic". I understand the notion of identifying the various representations, but it seems to me that there is a large common subset of most of these: decimal-scaled integers, with the scale (the power of ten) often held separately from the significand (and both, initially, in packed decimal, and later in binary, but with the SAME arithmetic properties; the scale was often not exposed numerically as it was part of the "picture", or field type). In other words, decimal fixed-point arithmetic. (Well, that's how I remember it. I presented caveats before.) The new DFP formats permit the scale to be represented in the same datum as the significand, but can that be exploited if the code has to be executable with a non-DFP-based arithmetic as well? I guess so, for traditional fixed-scale fields. The new floating-point fields would in fact not exploit the DFP cohorts, as earlier posts indicated that all floating-point items are considered as if normalised. If the logical representation remains as decimal-scaled integers, binary128 should be capable of the same arithmetic as DFP (up to 34 digits) and BCD as Packed Decimal (up to 31 digits), right? Different arithmetic properties would then show up only when narrower formats are used (binary64 and even decimal64), as rounding effects become an issue. The new floating-point formats also support a large magnitude range with dynamic scaling (and, in the case of DFP, with the ability to get exactly the same results as laborious static scaling). If this hunch is right, then I understand somewhat the obsession with encoding, because the purpose is not really to describe the arithmetic but is explicitly intended to describe the representations. What continues to confuse me however is why Endianness (and, for character fields, the character encoding) is not considered part of the encoding. Please -- is there ANYBODY out there who can tell me how this is handled in COBOL implementations, for cross-platform import/export of records? (One possibility would be that all import/export is done in character decimal, for numeric fields, in which case Endianness indeed disappears as an issue, and only the Ascii/Ebcdic/... distinction remains, which is a horse of another colour. But in that case BID/DPD would not be an issue either -- which brings me back to my initial confusion.) Michel. ---Sent: 2011-02-27 02:21:55 UTC

**Follow-Ups**:**RE: A general comment on COBOL "modes of arithmetic"***From:*Charles Stevens

- 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: Potential modifications to COBOL relative to IEEE 754** - Next by thread:
**RE: A general comment on COBOL "modes of arithmetic"** - Index(es):