RE: Nate's objections to Motion 42
Michel Hack wrote:
> Nate Hayes wrote:
> > ... These two decorations can be merged into a single "not defined"
> > decoration (ndf), since both
> > sqrt([-2,-1]) and text2interval("friedchicken")
> > are "not defined," just as you have said.
>
> In other words, there should (in Nate's view) be NO DIFFERENCE between
> text2interval("friedchicken") and text2interval("Empty"). Neat -- we
> don't need to reserve a name for Empty. Another simplification.
>
> However, Nate DOES seem to want a difference between
> sqrt(Empty) = Empty_EIN
> and
> sqrt([-2,-1]) = Empty_NDF
>
> Go figure!
Well... as has been explained several times before in examples with
piecewise functions, this distinction is required for correct decorated
intersection and hull operations. The lack of this distinction is the reason
the Motion 42 scheme is not able to handle these decorated operations
without generating contradictory results. :(
>
> Ok, let's be serious now.
>
> I suppose the difference between friedchicken and Empty is that the
> former leads to a bad Empty_NDF and the latter leads to a good Empty_emp
> (or, if we drop _emp, Empty_trv). I believe it is imperative that we
> preserve the distinction between good Empty (e.g. resulting from an
> intersection, or from a constraint having no solutions)
This has been pointed out many times before, but a decoration scheme that
allows Empty to be decorated with EIN, DAC, etc., allows, e.g.,
([1,2],DAC) intersect ([3,4],DAC) = (Empty,DAC)
This is not possible in the Motion 42 scheme of things, and emp or ill don't
do anything to solve this problem, either.
> and a bad Empty
> (possibly not an interval at all). If we drop both _ill and _emp, we
> are in deep doodoo. Unfortunately I'm not convinced yet that Nate's EIN
> is a conflict-free solution.
Can you demonstrate or give examples of what you perceive are the conflicts?
That would be helpful.
>
> The reason I see a difference between sqrt[-2,-1] = Empty_ndf and
> text2interval("friedchicken") = Empty_ndf is that the former can
> arise legitimately when domains are split up into pieces, and it
> makes sense to track what is happening to the pieces, whereas the
> latter is definitely Not an Interval and it should be possible to
> be alerted to its occurrence as soon as practical.
If an implementation throws exceptions, a user will always be alerted as
soon as the invalid construction is encountered, regardless what the
decoration scheme is. So it's a moot point.
If an implementation doesn't throw exceptions, a user will typically check
the decorated result of some lengthy computation. The emp or ill decorations
don't provide any advantage in this scenario.
Nate