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

RE: Two technical questions on IEEE Std 754-2008



Chuck Stevens wrote:
in the FCD, we already support FOUR modes of arithmetic:

(I'm guessing:  Future Cobol Directions?)

One of the things that the 754 WG worked hard on was to ensure that
DFP arithmetic be IDENTICAL for the two possible encodings, BID and
DPD.  For example, BID could represent slightly larger coefficients
than DPD (2**113 > 10**34), but such representations are not only
non-canonical -- they have a defined value (namely zero) that is
within the same range as possible DPD-encoded values..

So I think it would be wise to avoid specifying too much at the
language level.  What you should consider (in my opinion) is means
to tag data fields (not the contents) at the IMPLEMENTATION level
as to encoding, to be prepared for implementations that might have
native BID support.

I'm assuming here that COBOL implementations already have a means
of recording the type of numeric fields: 31-digit packed decimal,
Binary128, Decimal128, or some "native" format such as 128-bit binary
integers.  If you could at the IMPLEMENTATION level distinguish the
two Decimal128 encodings, you would be fully prepared to support
native internal arithmetic as well as a standard interchange format
(which would then be DPD-encoded if specified as COBOL Decimal128).
The re-encoding functions defined by 754-2008 were defined to permit
environments supporting both encodings to be implemented themselves
in a portable manner, precisely so as to hide the issue from the vast
majority of DFP programs.

  STANDARD-DECIMAL (FCD): Arithmetic is performed using decimal128,
  content is always normal from the view of the program

I assume that "from the view of the program" means that you don't rule
out implementations that take advantage of the ability of DFP to emulate
fixed-point arithmetic, without the need to record the scale separately
as is necessary for plain packed decimal.  After all, the whole point of
the 754-2008 specification for DFP being different from 854 was to exploit
unnormalised representations.

Michel.
---Sent: 2011-02-23 17:51:04 UTC


754 | revision | FAQ | references | list archive