Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Reasons (not) to vote Motion 27: NO



Vincent et al,

I'm still a bit confused about specifying over "free expressions"
versus "bound expressions," since my perception of the scope
of the standard is specification of individual operations,
rather than in the parsing of expressions in a programming
language.  However, I suppose we can define the individual
operations (including possible decorations) according to
their effect on expressions, and whether or not we are
thinking of free expressions or bound expressions would
affect how we do this.

Best regards,

Baker

P.S. I also think Arnold has a point with regard to
     the impossibility of making programming totally error-proof.
     We can develop a hammer with a head that will never
     or become disconnected from the handle, a handle
     that will never rot or break, and a shap that transfers
     virtually all of the force to the nail, without
     slipping.  However, it still may not work well if
     someone tries to use it to open a jammed door or,
     more absurdly, at the end of a fishing line to try
     to catch fish.

On 08/18/2011 09:07 AM, Vincent Lefevre wrote:
On 2011-08-18 14:58:49 +0200, Arnold Neumaier wrote:
On 08/18/2011 02:26 PM, Vincent Lefevre wrote:
But here the risk is even more important, because the behavior isn't
intuitive and existing programs would need to be modified. Indeed,
existing programs do not use decorations (or at least, not the ones
defined in Motion 26), and the problem here concerns the decorations
only.

But the risk is easily avoided by following the instructions in the
standard (which can be emphasized by giving your example).

The current motion is not clear enough. Here it seems that the
difference between a bound expression and a free expression really
matters (contrary to floating-point arithmetic or to interval
arithmetic without decorations). In my example:

   r = sqrt(x) + y;

and this could have been rewritten:

   z = sqrt(x);
   r = z + y;

but there is a difference between f(x) = sqrt(x) and f(x,y) = sqrt(x).

Note: both a bound expression and a free expression can define a
function, but not in the same way. In the case of a free expression,
the function arguments are implied by the expression itself.

I think the main problem is that 5.8.5 doesn't say when Step 1 is done
exactly. I initially thought that I was done locally at each leaf, i.e.
x ->  domain(x) for sqrt(x), and y ->  domain(y) for the addition.

Also, I suppose that domain() should never be implicit as it can
transform a non-empty component into an empty one.

Now, languages are often based on free expressions. So, shouldn't
the standard specify decorations over free expressions (possibly
in addition to specification over functions or bound expressions)?

Said that, I still don't think that 5.8.5 is correct. Consider:
   * xx and/or yy is Empty (so that the box (xx,yy) is empty).
   * f(x,y) = sqrt(x) + y
One gets:
   * After applying domain on the box (xx,yy), one gets (Empty,emp)
     for both components.
   * For zz = sqrt((Empty,emp)), if one applies (Eval3) directly, then
     one gets d = min{e,emp} with e>= con, thus d = emp.
   * For zz + yy, if one applies (Eval3) directly, then one gets
     d = min{e,emp,emp} with e>= con, then d = emp, while one would
     expect d>= con according to (8) since the box (xx,yy) is empty.

Decorations are designed not for arbitrary computations with intervals,
but for the range evaluation of a function with accompanying guarantees
for this function in the domain on which it was evaluated.

You don't even define a function, hence are strictly speaking outside
the domain of applicability of the decorations.

Well, I partly disagree. See my remarks on free expressions.



--

---------------------------------------------------------------
Ralph Baker Kearfott,   rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
(337) 482-5270 (work)                     (337) 993-1827 (home)
URL: http://interval.louisiana.edu/kearfott.html
Department of Mathematics, University of Louisiana at Lafayette
(Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
Box 4-1010, Lafayette, LA 70504-1010, USA
---------------------------------------------------------------