| GOOD CATCH. I had lost sight that voting on Motion M0052 Clause 6 Text is scheduled to end TOMORROW, Friday, 14 Dec.
Current tally: Yes - 6; No - 0; Needed for quorum - 30.
PLEASE VOTE ! ! !
George Corliss P1788 Voting Tabulator
Dear colleagues,
my vote is YES on motion 52.
Best regards,
Andreas
Begin forwarded message: From: John Pryce <prycejd1@xxxxxxxxxxxxx>
Subject: Motion 52: final "Expressions" text for vote
Date: November 19, 2013 at 8:08:44 AM CST
To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
P1788
Attached is the version of Clause 6 "Expressions" that I would like voted on.
It is nearly the same as the version of 2013 Nov 4, at 23:44.
- Michel Hack suggested minor changes, which I have done.
- Vincent Lefevre criticised the end of §6.1, about computational equivalence
-- it used to say "affects efficiency but not the numerics of what is
computed" and I made it more precise in the Nov 4 version. Vincent was
still not happy with this. See extract of email exchange below.
I was hoping Vincent would offer a rewrite of the last three paragraphs of §6.1, but haven't heard from him yet. So I have added two sentences to the penultimate paragraph of §6.1:
"In finite precision, it is assumed that at corresponding points of a graph,
code list or algebraic _expression_ the same version of the relevant operation
is used. For example, storing and using intermediate results in IEEE 754
extended (80-bit) precision counts as using different operation-versions
from using double (64-bit) precision throughout."
I hope this does the needed clarification without being over-long.
Chair, I would like the voting on Motion 52 to start.
Webmaster, please put this text on the web site.
Regards
John Pryce
-------------------------------------------
On 2013 Nov 16, at 17:18, John Pryce wrote:
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.
|