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

RE: Two technical questions on IEEE Std 754-2008

Chuck Stevens wrote:
And for COBOL to be forced to note that, say, FLOAT-DECIMAL-34
and FLOAT-DECIMAL-B-34 are, as far as IEEE Std 754-2008 and
its working group are concerned, REALLY exactly the same format
(decimal128), just interpreted in different ways, is not something
that makes sense to me, nor do I think it would make sense in the
COBOL world.

I can understand his concern based on the limited information he had
between 2006 and 2009.

However, by now those concerns should have been laid to rest:
Given a copy of the approved draft in the form of the published
standard, I can now see the advantages of both encodings, and can
now trust that each can exactly represent decimal values within the
permitted magnitude values.  I didn't have enough details on the
binary encoding to verify to my satisfaction that the representation
of decimal values in binary form was indeed specified as exact until
I saw the published version.

So how can I convince Chuck that COBOL does not need separate ARITHMETIC
attributes for the two possible DFP encodings?  If they were needed, it
would in fact be necessary to have FOUR arithmetics for STANDARD-DECIMAL
and TWO for STANDARD-BINARY, in pairs for different byte orders.  Luckily
there are (I think) only two byte orderings to worry about, unlike older
floating-point formats (remember the VAX?) that were mixed-Endian.

The only issue the language has to worry about is interchange formats,
and those have to address Endianness, character encoding, and other
details of the same nature as BID vs DPD for STANDARD-DECIMAL.  Given
the time constraints it may be reasonable to stick with DPD, at least
for now.  At some point whatever mechanisms are used to deal with these
other encoding issues could be updated to reflect BID vs DPD also -- or
not, if the COBOL community is happy with a fixed choice, and the cost
of in/out conversions (NOT conversions for every arithmetic operation)
on native-BID platforms is acceptable.

The other issue Dan Zuras raised -- handling of infinities, overflow
etc -- is unrelated to decimal (of any flavour) -- and it DOES affect
the ARITHMETIC.  I agree with Chuck that this cannot be solved in the
few month's time that appears to be available here -- and Dan knows
painfully well how standards can be delayed seemingly forever unless
someone with a steel fist creates order out of chaos...  Is it perhaps
the case that the kind of financial forecasting applications that need
genuine floating-point arithmetic tend NOT to be written in COBOL?  I
seem to recall that the financial industry actually liked APL...  With
sufficient inter-language calling mechanisms this may be how it works;
I would not know.

---Sent: 2011-02-25 03:04:46 UTC

754 | revision | FAQ | references | list archive