Re: Two technical questions on IEEE Std 754-2008
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.
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.