Re: motion21

[Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>]

Jürgen Wolff von Gudenberg wrote:
> Baker,
> please find attached the revised version of our position paper
> overlapping.pdf
> [...]
> This motion is to be understood as a supplement to motion 13.04.
> The advantages are outlined in the position paper that serves as
> rationale for the motion.
> Note that we do not want to change the traditional way of interval 
> comparisons as outlined in motion 13.04 but we want P1788 to provide  an 
> additional way as an option, that may offer some new kind of applications.

But none of these new kinds of applications are mentioned in the rationale.


The motion and its rationale show that these operations can be defined
and are in some sense complete (and hence quite numerous).

What is missing are reasons supporting the importance of the proposed
predicates. A standard should specify only what is important, not what
can be defined. There are endless possibilities for the latter.

The rare users who needs one of these operations can easily program the
needed one on the fly, and don't need a standard library (where even
identifying the right one may be more confusing and time-consuming than
implementing one's own.)


As far as I can tell, applications never need interval comparisons or
overlap relations per se.

What is needed are interval extensions of case statements, which
involve real comparisons, and a mechanism must be provided that
can handle these.

Using interval comparisons or overlap relations as this mechanism
is awkward. In addition, it is incompatible with the decoration
concept since there is no way to account for exceptions.


The appropriate mechanism is via interval extensions of boolean
functions, considered as functions with two possible values 0 and 1.

In the global optimization environment COCONUT, a function
   f = g(x) if b(x),
       h(x) otherwise,
where b(x) is a {0,1}-valued function, is encoded by something
amounting to
   f = case(g(x),h(x),b(x))
using a ternary operation case. The interval extension is computed using
interval extensions gg of g(x), hh of h(x) and bb of b(x), and then
   ff = union(gg,hh)  if bb contains [0,1]
        gg            elseif bb contains [1,1]
        hh            elseif bb contains [0,0]
        Empty         otherwise
This accounts correctly for the bare interval part.

The behavior on decorated intervals is then defined according to their
standard worst case semantics. For example, to distinguish between
bb=(Empty,safe) when x=(Empty,safe) and bb=(Empty,invalid) when
x= (Empty, invalid), the decoration part of an Empty bb must propagate
to ff.

For bb, one could use boolSets in place of bare intervals, but not in
place of decorated intervals, since the decoration part is lost in a
boolSet representation of bb, and ff cannot be assigned the right
decoration when bb is Empty. (So one would have to define decorated
boolSets. But it is preferable to keep the number of new data types
small!)