Re: M0020.01 Comparing comparisons NO

[Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>]

Dominique Lohez wrote:
> Arnold Neumaier a écrit :
> > [was this intentionally off the list?
> > If not, feel free to repost it to the list together with your reply.]
> >
> > Dominique Lohez wrote:
> > > Arnold Neumaier a écrit :
> > > > Dominique Lohez wrote:
> > > > > Vladik, John, p1788
> > > > >
> > > > > I completely  agree with the fact that the set of interval 
> > > > > comparisons must be slim.
> > > > >
> > > > > However it is not enough  to state that to be conformant to the  
> > > > > Standard some interval comparison  must be provided.
> > > > >
> > > > > It must be stated  in the standard that
> > > > >
> > > > > NO ADDITIONAL COMPARISON MAY BE PROVIDED.
> > > > >
> > > > > Otherwise you may be sure that some vendor will  add some "very 
> > > > > convenient"  comparison. 
> > > >
> > > > Yes, and what's wrong with that? Every programmer can add their own
> > > > comparison anyway.
> > > I think I have  misunderstood your position
> > > What you require is that only three comparisons are mandatory in the 
> > > standard.
> > >
> > > I think that the possibility for the user to introduce additional 
> > > comparison should be severely restricted.
> > > The rationale is that adding new comparison may completely change the 
> > > mathematical nature of the intervals we are dealing with
> > >
> > > To detail my position I consider the much more simple case of numbers.
> > >
> > > If the only comparison allowed between numbers is Equality :
> > >        Then the comparable   numbers may be integers, rational , 
> > > floating point numbers, real  numbers  and even complex numbers .
> > >
> > > If the less comparison is added             The complex numbers are 
> > > no more comparable numbers
> > >             Furthermore comparable numbers can now be sorted,  
> > > intervals can be defined , etc
> > > Thus we do  not  work with the same mathematical objects  in both cases.
> > >
> > > IMHO the standard should  define the nature of   the mathematical  
> > > objects we  are working on.
> > >
> > > In that context adding new comparisons should be discouraged,  and 
> > > only left to users( and not vendors) who know what they are doing.
> >
> > Aren't vendors more likely to know what they are doing than users?
> Yes of course
> My purpose was to prevent that wild extensions  may be provided to 
> unaware users
> > Anyway, since intervals are defined as sets by topological conditions,
> > it is natural that the topological comparisons are provided, snce they 
> > are part of the structure anyway.
> I agree
> > I don't really care about the others, though leaving them optional would
> > probably make it easier to reach a consensus.
>
> It may remain a problem :
> All the significant extensions namely the  the exclude the emptyset from 
> the  set of comparable intervals.
> and it is essential to topological properties.

With my proposal to provide only the comparisons
    isIn, isInterior, isDisjoint
and perhaps
    isEqual,
(and perhaps together with their negations), there is no such problem.

Indeed, in the context of Motion 3, these are the only natural
comparisons.

The proposed use of other comparisons in a branch-and-bound context
to handle the order in which boxes are handled is too simple-minded,
since
-- in pure constraint satisfaction problems where the search finishes,
   the ordering of the boxes is completely immaterial, and a last-in
   first-out stack will do the ordering most flexibly without any
   comparison at all,
-- in all other cases, the ordering must be determined dynamically
   anyway, to take account a measure of the likelihood of finding
   a solution in za particular box.


Arnold Neumaier