| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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.
Attachment:
20131119Clause6Expressions.pdf
Description: Adobe PDF document