RE: Nate's objections to Motion 42
John Pryce wrote:
> > For
> > example, section 8.8.7 says decorated intersection operation may provide
a
> > decoration min(dx,dy), where dx and dy are the decorations of the input
> > operands. So this gives:
> >
> > ([1,2],dac) intersect ([3,4],dac)
> > = ([1,2] intersect [3,4],min(dac,dac))
> > = (Empty,dac)
> >
> > But by section 8.8.4 the empty set is not permitted to be decorated with
> > decoration dac, so the specification allows implementations that give
> > contradictory results.
>
> You are quite correct. This shows the danger of specifications that are
> ad-hoc instead of derived from the mathematics. Back to the drawing board
> with these (optional) versions of intersection & convexHull.
> I regard these as of secondary importance; unless someone comes up with a
> proven consistent spec of them, I'll drop them from the next draft.
The scheme with EIN properly defined allows the intersection and convex hull
operations to be decorated and give consistent and non-contradictory
results. I have not ever seen any other decoration scheme so far that allows
this, including Motion 42.
> > -- I believe everyone agrees Empty is a set. But if Empty is also an
> > interval, then to call (Empty,ILL) a "decorated interval" on the one
hand
> > and "not an interval" on the other hand doesn't make any sense to me (it
is
> > a contradiction);
> Your intersect bug is an issue of substance. This complaint is just
> about use of language. One could rename (Empty,ILL) as BadInterval. My
> reply to Guillaume gives (Empty,ILL) a theoretical backup, but I think
> its main justification is pragmatic (8.8.3): a failed constructor call
> needs to return *something* at level 2, and this is a good candidate.
As you've told me before, at Level 1 a constructor is just an interval
function that takes non-interval arguments. A failed constructor, therefore,
is just an out-of-domain evaluation of a function, similar, e.g., to
sqrt([-2,-1]) = Empty. IMO, the efforts to treat failed constructors
differently is adding a lot of unnecessary confusion and complexity to the
standard for what I see as no additional benefit.
> > -- The ILL decoration may require strong Computer Algebra System
> > (CAS) to prove; and even if such CAS is available, the ILL decoration
may
> > not always be provable. I think this decoration is unnecessary, too
complex
> > and should be dropped;
> This has been answered by me and others.
What is the answer?
> > -- Since Motion 42 does not allow Empty to be decorated with
> > decorations such as DEF and DAC, the motion must define these bare
> > decorations as the compressed decorated intervals (Entire,DEF) and
> > (Entire,DAC) respectively...
> Why?
Because Motion 42, section 8.8.4 says it is a "contradiction" to decorate
Empty with DEF, DAC, etc. to form these decorated intervals.
In a decoration scheme different from Motion 42 which allows Empty to be
decorated with DEF, DAC, etc., the example from my previous e-mail becomes:
[1,2] \subseteq floor([5,6])
= [1,2] \subseteq ([5,6],def) // Full decorated result
= [1,2] \subseteq def // compress non-DAC result
= [1,2] \subseteq Empty // promote bare decoration def to
Empty
= false
In other words, the bare decoration promotes to Empty instead of Entire, and
the algorithm no longer experiences failure.
> Decorations, decorated intervals and compressed decorated intervals
> are 3 quite different types (or families of types at Level 2 in the case
> of the latter two) of objects. Your example in the following paragraphs
> makes no sense to me. It seems to follow an error (IMO) in Motion 8,
> which was written at a time when we didn't understand the need to treat
> them as separate types.
What error? I don't understand what you're talking about. Can you be
specific? Give an example?
> >
> > -- I understand compressed interval arithmetic was removed from
> > Motion 42, but it appears these problems will remain when we do get to
it.
>
> No. It will follow Arnold's original "worst case scenario" system, which
> cannot give contradictions.
I don't know what this is, or what it means. Is it already part of Motion
42? Can you show with the example above how this "worst case scenario"
system will not lead to a false positive?
> > -- Decoration system with EIN that gives containment order
> > EIN \subseteq DAC \subseteq DEF \subseteq GAP \supseteq NDF\supseteq
EIN
>
> There are *many* decoration schemes that give consistent and useful
> results when correctly implemented and used. Motion 42's scheme and
> yours are both in that category, I believe, but I prefer a scheme where
> the reduced-graph of the containment order is a tree, not a DAG that
> "joins up":
> Motion 42 Kaucher group
> trv GAP
> / \ / \
> emp def NDF DEF
> / \ | \
> ill dac | DAC
> \ \ /
> com EIN
>
> I think the tree model will prove easier for users to understand.
IMO, the question isn't about what's easier to understand (and I don't
believe a DAG is any harder to understand than a tree, BTW). It's about what
decoration system gives all the features necessary for an interval standard
and provides useful and consistent results when correctly used. If decorated
intersection and convex hull are to be part of the standard, the decoration
scheme in Motion 42 does not satisfy this criteria. The scheme with EIN is
the only scheme I've seen so far that allows Empty to be decorated with DAC,
DEF, etc., which is required if those decorated operations are to be
included in the standard.
From a mathematical point of view, the fact that EIN is a subset of every
decoration is similar to the idea that Empty is a subset of every set, e.g.,
if f is a real function, the restriction of f to Empty is true for any
predicate.
Nate