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

Re: Two technical questions on IEEE Std 754-2008

To: <khbkhb@xxxxxxxxx>
CC: <forieee@xxxxxxxxxxxxxx>, IEEE 754 <stds-754@xxxxxxxxxxxxxxxxx>
Subject: RE: Two technical questions on IEEE Std 754-2008
Date: Thu, 24 Feb 2011 10:40:24 -0700

. . .

As a side note:  it's been argued that IEEE arithmetic is the same regardle=
ss of the encoding.  Offhand=2C I don't see anything that requires that dec=
imal-format operands to IEEE arithmetic operations be in the same encoding=
=2C 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 bina=
ry-encoded decimal128 item will NOT be the same as it would if both were en=
coded in decimal in the first place.  The results are (almost?) always vali=
d numeric values=3B they're just wrong if the presumption is that the opera=
nds and the result are all in the same encoding.  This is the same dilemma =
COBOL faces if the presumption is that the data in IEEE decimal formats is =
encoded in decimal=3B the difference is that COBOL explicitly states that o=
nly decimal is permitted to begin with.   

    -Chuck Stevens 


        As you seem determined to follow your current path
        I thought I had written my last word on this subject
        but I guess I have another one in me.

        This is a false analogy.

        It is equivalent to saying that adding a DPD encoded
        Decimal128 to an ASCII string would be dangerous.
        Of course it would.  If it hurts, don't do that.

        Anytime you import data without knowing its format
        you make such errors.  Almost always fatal.

        We spent at least 2 years putting decimal arithmetic
        into 754.  About a year & a half shoehorning it in
        in the first place.  And later, another 6 months or
        a year when the conflict between IBM & Intel came up.
        But we resolved all that.

        And we did it for you.

        The arithmetic *IS* identical in both DPD & BID.  We
        made damn sure of that.

        That you don't seem to be interested in using both
        encodings wastes that latter time.  That you don't
        seem to be willing to support decimal even to the
        point of changing the fundamentals of the arithmetic
        WRT NaNs & infinities wastes the rest.

        I was hoping to persuade you to make your variances
        much more slight (in the form of more Cobol-like
        exception defaults) but even that has gone nowhere.

        I'm sure you know far better than I what is best for
        your users.  And what you can do in the time you have
        available to you.

        But it seems a shame.



754 | revision | FAQ | references | list archive