Re: Comments on decoration ill, intersection and union
On 2012-12-01 11:19:27 -0600, Nathan T. Hayes wrote:
> John, P1788,
>
> It appears that knowing Dom(f) is empty requires global knowledge of the
> function f. For example, some Computer Algebra System (CAS) or a user's
> comprehensive run-time knowledge of an entire program may be required. But
> complicated functions may be composed from collections of smaller functions
> or subroutines that are part of pre-compiled libraries, for instance, so
> even a CAS may not be able to prove the ill decoration. This leads me to
> think it should be dropped.
AFAIK, ill was introduced mostly for an "illegal" use of a constructor,
e.g. nums2interval(1,0) in the set-based flavor, then extended to the
cases when an implementation could deduce that a function is nowhere
defined (the implementation needs to be smart enough, because supplied
arithmetic operations are never nowhere defined in practice, only some
special composition can), and to incorrect constants like 1/0.
An implementation is not required to return the best decoration, as
said in §8.8.4. Also note that from the definition, ill implied emp
(if Dom(f) is empty, then xx inter Dom(f) is also empty), so that
there is no contradiction.
> On a different topic:
>
> Empty is a subset of any interval in set-theory. I think it is advantageous
> to have a decoration that has this property too, i.e., a decoration that is
> a "subset" of every other decoration. This would be the decoration ein for
> "empty input" with property p_ein(f,X) defined as X is empty, and the
> restriction of f to X is (vacuously) continuous.
>
> Removing ill and adding ein would give the propagation order:
> ein > dac > def > trv > emp
> and the exclusivity rule is satisfied such that ein is a subset of every
> decoration.
There were consistency problems with ein when it was introduced in
the past. So, you need to be careful. For instance, the min-rule
would no longer be valid, because ein could be transformed to dac,
which is wrong, as dac assumes that xx is nonempty. Moreover I wonder
whether it would be useful in practice: if the input is empty, then
the user should know that and doesn't need a decoration for that.
And there would be a problem with com too.
> This allows set-theoretic operations like intersection and union to be
> decorated. For example, the function in Example 2 on pp. 34-35 may be
> implemented:
> U = f1(X intersect [-oo,-2])
> V = f2(X intersect [-2,2])
> W = f1(X intersect [2,+oo])
> return U union V union W
X is the input. If it is not empty, you'll never get ein in the
propagations, unless you have special rules for ein. But the FTDIA
would need to be proved with that and all the possible uses of the
operations... For instance, an intersection could be used to check
whether some equation can have a solution. This wouldn't mean an
empty input.
On 2012-12-02 05:41:59 -0700, Kreinovich, Vladik wrote:
> It is my understanding (and it may need clarifying the text) that
> emp does not literally mean that Dom(f) is empty, it means that we
> have proven that Dom(f) is empty. Yes, of course, sometimes it is
> actually empty bit since we cannot prove it, we do not use this
> decoration.
Yes, exactly that.
--
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 / AriC project (LIP, ENS-Lyon)