Re: Reasons (not) to vote Motion 27: NO
On 2011-08-19 14:10:38 +0200, Arnold Neumaier wrote:
> On 08/19/2011 12:17 AM, Vincent Lefevre wrote:
> >On 2011-08-18 17:30:21 +0200, Arnold Neumaier wrote:
> >>One cannot give any useful guarantees for free expressions because
> >>one cannot control the input decorations. They can carry decoration
> >>information from ancient times that are completely irrelevant for the
> >>range calculations.
> >
> >On the contrary, AFAIK, this is the goal of decorations: to propagate
> >information from the input to the output.
>
> If you apply the domain operator to the input (as a single vector),
> everything is alright. But if you have multiple inputs with unknown past,
> there is not ''the input''.
Well, what I mean is that the computation can be modelized by a DAG,
and each node has its own input vector and output vector. If one
considers:
[A]
z = sqrt(x)
r = z + y
Here the sqrt node has input x only (not the box (x,y)), and the + node
has input (z,y). Here x and y may already have initial decorations, e.g.
because they can come from output of other nodes.
IMHO, one should focus on properties that depend only on the explicit
inputs. What I mean here is that on the example, what the decorations
can say about z should not depend on y. Or if one wants to make z
depend on y, this should be done explicitly; I think this is the goal
of domain(), e.g.
[B]
(x',y') = domain(x,y)
z = sqrt(x')
r = z + y'
But, depending on what the user wants, it should be his decision to
choose [A] or [B]. Differentiating ein and emp works with [B], but
not with [A].
> If one deletes the decoration ein (which was not in the original set of
> decorations anyway, but was added because of prior demand), and uses emp
> instead, things also work alright for free expressions.
Yes.
> > IMHO, the decoration system, defined by the specification of the
> > individual operations, should be meaningful on free expressions.
> > Motion 26 does probably too much by differentiating ein, emp and
> > ill (is it really necessary to differentiate them?).
>
> There is no harm in differentiating emp and ill, and it carries useful
> information.
OK, except that ill should then be changed to "Domain(f) is empty."
(i.e. dropping the "x is nonempty").
However I'm wondering... ill is a global property of f, while def, dac
and bnd are properties local to x (i.e. how f is defined outside x
does not matter). Is this intentional?
I think this can be a (minor) problem, because the implementation of f
can focus on an interval where it will always be evaluated in practice
(the implementation is still required to be correct, though). However
the only risk would be non-optimal results. Anyway, I suppose that the
goal of ill is to detect bugs (because defining a function nowhere
defined doesn't make sense), and the worse that can happen is an
undetected bug.
I have thought about the local version "x is disjoint from Domain(f)",
but it is already implied by "f(x) is empty".
BTW, I suppose that if the (only) function f with 1 argument such that
Domain(f) is empty is implemented by sqrt(-1/x^2), then one cannot
obtain the ill decoration (except if the code knows that Domain(f) is
empty and forces the decoration to ill, or the implementation does an
optimization like supporting open intervals internally), even though
this would be a correct decoration. Said otherwise, the decorations are
properties associated with functions, not with their implementation.
So, if a programmer writes code based on the fact that all intervals
are closed (like assuming that 0 is in the interval returned by the
expression sqrt(-1/x^2) when x is unbounded), it would be a mistake.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)