Re: Motion 52: final "Expressions" text for vote
John,
Section 6.4 still says:
> The standard requires that at Level 2, for all interval types, operations and inputs, the inter-
> val part of a decorated interval operation equal the corresponding bare interval operation.
My opinion is that "for all inputs" quantifier should be more specific:
<<<
The standard requires that at Level 2, for all interval types, operations and inputs(other than NaI), the inter-
val part of a decorated interval operation equal the corresponding bare interval operation.
>>>
Please give a comment about this opinion.
-Dima
----- Исходное сообщение -----
От: prycejd1@xxxxxxxxxxxxx
Кому: stds-1788@xxxxxxxxxxxxxxxxx
Отправленные: Вторник, 19 Ноябрь 2013 г 18:18:25 GMT +04:00 Абу-Даби, Маскат
Тема: Motion 52: final "Expressions" text for vote
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.