| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Personally, I’d keep the standard as simple as we can and view intervals as a range of values. We have not much time. I am OK with offering a brief warning about the excess widening, but the standard is not the place for a course in wise construction of interval algorithms. My $0.02. George Corliss On Nov 3, 2013, at 2:57 PM, Michel Hack <mhack@xxxxxxx> wrote: > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail