[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: Clause 10, Expression Evaluation
Malcolm,
Perhaps I was a bit unclear; let me try again...
1) Unambiguously define all operations.
I am in complete agreement.
Would be nice if others were also.
On this topic, would you be interested in becoming a reviewer
of an IEEE document that provide unambiguous tabular definitions?
Not many $$(:<), but perhaps a sense of accomplishment(:>)
I agree as far an options are about operations, formats and so on,
That was all that was intended in my email, although others
have implied much more. Perhaps I was branded by the company
that I keep?
3) Specify which options are part of the "repeatibility" suite.
... we seem to be somehow falling off the "arithmetic" boat into
the "expression semantics" swamp. That swamp is the preserve of
Maybe I was unclear. All that I intended by (3) is the choice of
(somewhat hidden) standard options, including but not limited to:
a) Tiny rounding: before or after.
b) FMA: sNaN exceptions taken before or during.
(etc.)
As such, I believe this statement had not entered the
"expression semantics" swamp, nor to I feel qualified to do so.
Do languages *really* need guidance on that? I don't think so.
I don't know and I'm not an expert. I would defer to the
judgment of yourself and others. Are you on the 754 BRC?
Respectfully,
DVJ
-----Original Message-----
From: stds-754@xxxxxxxx [mailto:stds-754@xxxxxxxx]On Behalf Of
Malcolm Cohen
Sent: Thursday, July 12, 2007 7:15 PM
To: dvj@xxxxxxxxxxxx; Jason Riedy; Malcolm Cohen
Cc: stds-754@xxxxxxxx
Subject: Re: Clause 10, Expression Evaluation
On Fri, 13 Jul 2007 03:26:05 +0900, David James <dvj@xxxxxxxxxxxx> wrote:
IMHO, one needs to:
1) Unambiguously define all operations.
I am in complete agreement.
2) Clearly list all options.
I agree as far an options are about operations, formats and so on,
but ...
3) Specify which options are part of the "repeatibility" suite.
... we seem to be somehow falling off the "arithmetic" boat into
the "expression semantics" swamp. That swamp is the preserve of
the language alligators - be careful or you'll get eaten!
Sorry, but the idea that 754R should pontificate on How Languages Should
Support Users Debugging Their Programs is (IMO!) just wrong. It has
little or nothing to do with standardising arithmetic.
Not to mention my strong disagreement with the suggested mechanisms.
As my misunderstood analogy went, there is little point in a special
"go-slow" mode that is reproducible when the production mode does not
have those characteristics.
4) Provide guidance on how languages "could" follow through,
to ensure repeatability, within an informative annex.
Do languages *really* need guidance on that? I don't think so.
To the extent that a language cares about repeatability, it will
already be doing things to support repeatability; if the arithmetic
operations are defined properly in 754R, that is highly likely already
to result in repeatability.
To the extent they don't (care), they don't,
and shouldn't be told that they should!
Cheers,
--
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.