RE: Promotion of bare decorations & comparisons
John Pryce wrote:
> On 7 Jan 2013, at 15:51, Nathan T. Hayes wrote:
> > John Pryce wrote:
> >> "A decorated interval yy_dy shall always be such that yy \supseteq
Rge(f|x) and
> >> p_dy(f,x) holds -- informally, it must tell the truth about
> >> some conceivable evaluation of a function over a box."
> >>
> >> I think it is definitely *not* the case for your system.
> > ???
> > Please demonstrate why you think this.
> > If you can provide some specific examples, that would be helpful.
>
> It seems I was wrong, thanks to mixing up lowercase decorations with
uppercase ones.
> As I understand it, your uppercase "tracking" ones correspond to motion 42
lowercase
> ones and the lowercase "static" ones are equivalent to the "tightest
decoration"
> function dec(). I.e. p_d(f,xx) holds for a static d in your system, iff d
= dec(f,xx) in
> motion 42 (allowing for the systems' different sets of decorations).
This is how I understand it, as well.
>
> Are the permitted combinations in your system as follows?
> yy
> +------------------
> dy | empty nonempty
> +------------------
> EIN | y n
> DAC,DEF,GAP,NDF| y y
Yes.
> You wrote (On 5 Jan 2013, at 21:06):
> > -- Empty may have "good" (DAC) and "bad" (NDF)
> > decorations/interpretations
> Suppose I evaluate an arithmetic expression, and the result is, say,
Empty_DAC. What
> useful conclusion can I typically draw from this?
Please see the 12/14/2012 e-mails on the P1788 reflector which already
started this discussion in some detail. I've attached a copy for
convenience.
> You also wrote in that email
> > -- If Empty is not an interval, compressed interval arithmetic
> > avoids the false positives/negatives
> Do you mean, here, that it's just in compressed arithmetic that Empty
isn't an interval?
IMO this would be inconsistent... so I hadn't considered that possibility.
To me, it is an interesting puzzle to consider:
i) that the "decorated interval" (Empty,ILL) is called "not an interval"
vs.
ii) the idea that Empty is an interval.
From a mathematical point of view
f(x) = x + 0/0
is not defined for any x, but for any interval X
f(X) = X + 0/0 = Empty.
If Empty is an interval, how can the result be called "not an interval?"
It seem that ii) by definition makes i) a contradiction.
It doesn't make any sense to me.
However, it does make sense to me to say that Empty is "not an interval," or
even more specifically in this example that "f(X) is not defined because the
result is not an interval".
> A remaining question from my last email: please explain how this system
handles
> invalid constructor calls.
I have an old e-mail from you that says:
On October 24, 2011, John Pryce wrote:
> To me, a constructor is any interval-valued mathematical function having
non-interval
> input(s).
...
> So interval(1.2, 3.4) and interval("[1.2,3.4]") might be Level 1
constructor calls.
> (Vienna proposal calls them num2interval and text2interval I believe.)
I basically agree. The meaning of this statement is that a constructor is
just a normal function with a natural domain.
When a function like sqrt is evaluated outside its natural domain, say on
the interval [-4,-1], the decorated interval result is (Empty,NDF).
IMO, a constructor is no different: invalid construction is just evaluation
of the constructor function outside the natural domain of the constructor.
So (Empty,NDF) may be the result of an invalid constructor call.
NOTE: if Empty is not an interval, the invalid construction (Empty,NDF) may
still be described as "not an interval", or more specifically one could say
"the constructor is not defined because the result is not an interval".
Nate
--- Begin Message ---
Vincent Lefevre wrote:
> On 2012-12-14 08:04:56 -0600, Nathan T. Hayes wrote:
> > Vincent Lefevre wrote:
> > > On 2012-12-13 16:29:52 -0600, Nathan T. Hayes wrote:
> > > > If we evaluate the range of the intersection of X and Y, then
> > > > g([0,1] intersect [2,3])
> > > > = g(([0,1],DAC) intersect ([2,3],DAC))
> > > > = g((Empty,DAC)) // Empty input!!!
> > > > = (Empty,DAC)
> > >
> > > But the initial input is [0,1], which is not empty ([2,3] can be
> > > seen as a constant or another input, depending on the context).
> > > One gets Empty only after the intersect operation, and since this
> > > is after an operation, Empty cannot be an input.
> >
> > Precisely. This is why the (Empty,DAC) result is not meaningless: it may
> > imply the input was nonempty even though the result is empty.
>
> But what does it mean exactly?
It means: for all arithmetic operations in the lengthy computation that
occurred, the restriction of each arithmetic operation to the domain of its
respective input operands was defined and continuous, but the result is
still empty.
Therefore, (Empty,DAC) may occur for a couple reasons:
-- the input is nonempty, but the result is empty because of an
intersection operation (as in the case of this particular example).
-- the input is empty but there is at least one nonempty element of
the empty input box; or a nonempty constant is encountered in the
computation (similar to what you mention above).
When the interval portion of the result is nonempty, one can safely conclude
by the DAC decoration the input was nonempty.
Nate
--- End Message ---