Motion P1788/M0017.04 - Comparisons
There is little point in cramming into the standard complete
classifications of possibliities, unless these are actually useful.
I'd much prefer the standard to be slim but useful, rather than
comprehensicve but filled with stuff hardly ever used (especially
if it can be easily programmed by a user should the rare need arise).
If users have to lookup the manual to find out the meaning of the
various comparison operators, they are better off using in place of
the implemented version their own implementation, created using inf and sup.
Thus my proposal is to ban the multitude of possible comparison
operators and to opt for a minimal number of them rather than for a
comprehensive number. (Even the Vienna proposal still has too many....)
In the many years I did practical work on intervals, I never needed any
comparison of intervals except for three, only two of which are in the
list of seven proposed in the motion:
a.in.b (= a.subset.b)
a.interior.b
a.disjoint.b (= a.precedes.b or b.precedes.a)
These are the ones that make immediate sense for intervals as sets
(which is their main use). They are understandable directly and
unambiguously by their name, without the need to consult a manual.
The others might have nice theoretical properties, but practically, they
are virtually useless.
Or does anyone have an example for a real-life use of, say, the relation
<=, algebraically the nicest of those defined in the motion?
Even equality has no real use -- because of typical overestimation or
rounding errors, one cannot expect two intervals to be equal anyway,
unless one has simply cloned them.
Thus my recommendation is to vote NO on the motion, with the comment
that the vote would be reversed if only the relations in, interior,
and disjoint (and perhaps equal, for debugging) would be required.
Arnold Neumaier