Nate Hayes wrote:
Arnold Neumaier wrote:
Nate Hayes wrote:
Arnold Neumaier wrote:
Michel Hack wrote:
I vote YES on Motion 13.04 -- seven standardized interval
comparators.
This is a good compromise. Three may be theoretically
sufficient, but
implementations are likely to provide more, and it would be a
shame is
this resulted in a mess of similar but not identical operations.
Motion 13.04 says in the abstract: ''the number of comparison
relations
defined by the standard should be kept to a minimum.''
But Motion 13.04 provides only 1/3rd of the necessary comparisons,
and only 1/7th of the comparisons provided are necessary.
Thus the motion is self-contradictory.
Motion 13.04 requires 7 transitive relations,
only the second of which is actually useful.
The interior relation (the fifth) is not the topological one,
and hence will only cause confusion.
Two relations
disjoint
interior(topological)
-- both very important in practice -- are missing,
Thus Motion 13.04 is _not_ a compromise, but something quite
different from my proposal.
The disjoint relation is most efficiently implemented in hardware
and software in terms of the "preceding" relation in Motion 13.04:
disjoint(A,B) = ( A \prec B ) or ( B \prec A)
This can even be computed in a single overlapping operation (Motion
21). IMHO, your argument that disjoint is an important relation is
therefore evidence "preceding" is one of the relations P1788 must
standardize.
I rather regard your observation as a further argument against the
motion, since it invites inefficient solutions:
Your proposal replaces a single interval operation that is easy to
implement (with 2 real compares and 1 logical and) by two interval
operations and a logical and (requiring in total 4 real compares,
2 logical ands and one logical or), and overhead of almost a factor
of two.
This makes no sense.
Do you read the motions?
The relation A \prec B only requires a single floating-point compare!
disjoint(A,B) = ( A \prec B ) or ( B \prec A )
only requires two floating-point compares and a logical "or".
Oh, sorry, I didn't check the definition of \prec, and thought is was
composit like most of the others. Of course, you are right.
But then, why require users to code disjoint for themselves because
it is not specified in the standard, while providing new names for
operatins that are simpler and less useful?