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.