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

RE: Two technical questions on IEEE Std 754-2008



Chuck Stevens wrote:
As a side note: it's been argued that IEEE arithmetic is the same
regardless of the encoding.  Offhand, I don't see anything that requires
that decimal-format operands to IEEE arithmetic operations be in the
same encoding, or that the result of the operation is in that same
encoding.  It seems to me that the result of adding a decimal-encoded
decimal128 item to a binary-encoded decimal128 item will NOT be the same
as it would if both were encoded in decimal in the first place.

Mixed encodings should never happen.  As I said before, an environment is
expected to convert non-native encodings to native on the way in, and do
the reverse on the way out.  Yes, it has to know that the outside wants
or provides a different encoding -- and by fixing the encoding of external
data, this job is complete.  Input/Output would be DPD-encoded.  Surely
the run-time environment knows what its native or preferred format is,
so it knows whether it needs to use the encode and decode functions.

I'm a bit confused about why Chuck thinks this is still an issue.  Most
programming languages have an as-if rule when it comes to implementations.
Languages that support looking at raw bits (e.g. via unions in C or
EQUIVALENCE in Fortran) may have to be more careful in stating conditions
under which encodings may matter, but using type-violating overlays is
something programmers know already to be special in various ways.  Does
COBOL have this ability?  If not, it's a total non-issue, as it is not
visible from a program's point of view.  That's why I argued against
having COBOL add encoding-specific language features such as ARITHMETIC
IS IEEE-754-DECIMAL-ENCODING -- having STANDARD-DECIMAL is sufficient.

What *is* significant is COBOL's specification of the interchange format,
and that has been decided to be decimal-encoded (DPD), so as to avoid the
need to tag external media (files, sockets, ...) with an encoding ID.

Look:  Does COBOL require that integers be stored Big-Endian and that
character strings be Ebcdic (or Hollerith)?  The issues are similar.
Integer arithmetic is the same regardless of Endianness, and normally
the issue of adding a big-endian to a little-endian does not arise:
the run-time knows its Endianness, and when it imports or exports
data it needs to know whether endian-conversion is needed or not.

As a matter of fact, Endianness applies to the floating-point formats
too.  Perhaps Packed-Decimal has always been Endian-neutral, so perhaps
COBOL has never had to deal with this (given that "native" formats were
apparently opaque), but it certainly matters to the way binary128 as
well as decimal128 are stored.

The DPD vs BID issue of the same kind as Endianness.

Signed binary integer arithmetic (which may be foreign to COBOL) also has
the issue of One's-complement vs. Two's-complement.  Unlike Endianness this
DOES affect the arithmetic, so it's of a different nature.  (The value sets
for a given size are different; Two's-complement has one extra value.)

Michel.
---Sent: 2011-02-24 18:36:26 UTC


754 | revision | FAQ | references | list archive