Motion 26: NO

["Nate Hayes" <nh@xxxxxxxxxxxxxxxxx>]

I vote no on Motion 26.

To summarize, here are a few reasons:

   -- I don't believe the theory as presented in Motion 26 is valid (e.g.,
there are still contradictions, pointed out earlier by Vincent Lefevre).

   -- The bounded decoration is problematic, and I don't know an
algorithm that requires it.

   -- At Level 1, there should not be anything ill-formed.

   -- Not giving any specification for how intersection and union handle
decorations means users will invent their own (probably wrong) rules, i.e.,
what is the standard? Examples were given that show how incorrect handling
of decorations with intersection or union can lead to catastrophic failures,
so this is not something that should be left up to users.

   -- Structural induction (Motion 27-A1) is enough; we don't need a FTDIA
to compute decorations reliably when composing elementary operations into
complicated expression trees. Note the structural induction method has
precedent: it was used in the thesis of Jeff Tupper and his GrafEq program.

   -- If an implementer is using other methods (like endpoint analysis) to
add a function to an interval library, only the definitions for decorations
in Motion 27-A1 are required.

Sincerely,

Nate Hayes
Sunfish Studio, LLC