A general comment on COBOL "modes of arithmetic"
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.)
---Sent: 2011-02-27 02:21:55 UTC