Motion 52 -- Time to revive the "Expression" subgroup?
One of the issues that has irked me over the years is whether
an interval is intended to represent a single uncertain value
(as in evaluation of sensitivity to initial conditions), or a
range of values (as in constraint propagation).
I was reminded of this while examining Clause 6, "Expressions
and the functions they define", in the current P1788 Draft 8.1,
and the subject of Motion 52, which just reverted to discussion
mode for one more week.
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. To this I wanted to add:
Perhaps more significantly, when evaluated in interval mode,
multiple instances of the same variable can lead to excessive
widening of the final result; see Clause 6.x below.
I even drafted such a Clause 6.x, to be inserted between current
6.3 (The FTIA) and 6.4 (Related Issues):
6.x. The dependency issue. When the same variable occurs multiple times
in an expression, and the expression is evaluated in interval mode, there
are two possible interpretations: (a) the interval variable denotes a
single uncertain value, or (b) the interval denotes a range of values.
In case (a) there would be an implied dependency between two instances
of the same variable that is not present in case (b). The most extreme
example might be x-x which would be the singleton [0] when viewed as (a),
but would be an interval twice as wide as x when viewed as (b). Since
the evaluator (interpreter, compiler) typically does not know the intent,
it must assume view (b) in order to guarantee containment and the FTIA.
It also means that it must be possible to control compiler optimizations
that turn x-x into 0, x+x into 2*x, or x*x into sqr(x) -- and it explains
why the standard requires the presence of a Square function sqr().
I was however concerned about this, which is why I would like
to open discussion on this point:
(1) I'm a bit uncomfortable about having brought up the issue
of compiler transformations: is there a SHALL here? This
goes beyond issues of a so-called "reproducible mode".
(2) Is the above too closely related to the set-based flavor
to appear here?
I was discussing this with John Pryce, who replied:
| As for 6.x: the dependence issue needs to be discussed somewhere.
| But IMO your paragraph says too much for Clause 6 and too little
| for a proper exposition. I think
|
| - There should be a shorter description of the issue in §6.
|
| - It should be tied to an emphasis that an expression, whichever of
| the 3 descriptions of it is used, is taken literally operation by
| operation: if you replace x-x by 0 you have made a different
| expression.
|
| - Your 6.x is really a contribution of the Language Issues subgroup,
| which needs reviving! 6.x needs to become an informative Annex,
| and be expanded -- how much, I'm not competent to say. Would you
| take on that task? Ask for advice or help from others if you
| wish, but a solo effort may get the most done in the least time
| at this stage. Jürgen & Dima are in charge of Level 3 and the
| Annexes, so they would advise on just where the text would go.
I agree, so here we go.
Michel.
P.S. Initially I thought the common subexpression issue was peculiar
to the "algebraic expression" view, 6.1 (c), but John reminded
me that the issue is present already in the "formal expression"
view, which allows the output v of one formal operation to be
an input to several others, even though all inputs to a formal
operation (the u_i) have to be distinct variables. So my 6.x
is indeed general, and not particular to 6.1 (c).
---Sent: 2013-11-03 21:30:14 UTC