Re: Motion 52 -- Time to revive the "Expression" subgroup?
Vincent, P1788
You raise important practical issues here, but what I say is still
correct: I haven't said it clearly enough, so I hope you can help me
do so.
On 2013 Nov 15, at 10:13, Vincent Lefevre wrote:
> On 2013-11-03 15:57:06 -0500, Michel Hack wrote:
>> At the end of Clause 6.1 (c) one of the effects of repeated
>> subexpressions is mentioned:
>>
>> "If the algebraic expression is evaluated naively, such a
>> subexpression is evaluated more than once, which affects
>> efficiency but not the numerics of what is computed."
>>
>> Assuming no side-effects, this may be the only worry for *point*
>> evaluation.
>
> This is not clear. By "not the numerics of what is computed", does
> this mean the exact result (i.e. assuming infinite precision)? But
> this would be misleading after "evaluated".
>
> If this means the computed result on a machine,
which is what I mean,
> ... this is obviously incorrect in practice...due to extended precision
According to how I see it, this doesn't contradict what I said. What I'm
assuming is that *exactly the same library operations* are used in each
place where "the same" evaluation is being done. The operation starts
when its inputs are accessed from memory (possibly a register) and ends
when its result is stored in the form it will be used as a final output,
or as input to other operation(s). If the operation is performed, and/or
the result stored, in extended precision in one place and not in another,
those are two different (versions of) a given library operation.
> (some reported problems are actually not
> bugs: if IEEE 754 is not supported, then the C language does not
> guarantee that 1/3. - 1/3. gives 0). There may be similar problems
> with languages that allow a FMA to be used for x*y+z.
Two ways to change an expression-evaluation are being considered here.
(a) If the system switches from normal to extended precision, that's
*changing the versions* of library operations used.
(b) If it writes a*b + c*d as fma(a,b,c*d) or reduces x-x to 0, that's
*changing the expression* itself.
(Actually, the fma example might be interpreted as a case of (a).)
The text only says the result is invariant *if* one evaluates in a particular
way; it doesn't say that implementations *shall* do that. So all we need, I
think, is to make my text clearer, in the briefest possible way, referring
to the Annex that I hope Michel is writing for a fuller discussion, which
will no doubt include problems of reproducibility.
Can you help me with that?
I agree with the rest of your email; I had replied in a similar way to Michel.
John