My vote on Motion 13.04 is NO.
I like most of the spirit of the motion, and would change my vote to
YES if the following was changed:
The relations "a is less or equal to b" and "a is strictly less than
b" are, in my opinion, dangerous and confusing when stated this way.
If you interpret an interval to mean "the 'right' value is somewhere
in this interval, but I'm not quite sure where" (which is a common
interpretation implicit in many algorithms) then the < and <= operations
as stated *provide absolutely no guarantee that the 'right' value in a
is less than the 'right' value in b.* You can only make this guarantee
if the intervals are non-overlapping, that is, also checking that a2 <
b1, for instance.
Calling this a "less than" operator for overlapping intervals is
dangerous and deceptive, and will cause user confusion and algorithms
that function incorrectly. It's not a definition that captures the
spirit of "less than" as applied to real numbers. Renaming these two
operators to something less deceptive (and not using the < and <=
symbols for this) would be an adequate change in my opinion. For
example, changing them to be named something like "endpointsLessThan"
would be fine. Striking the definition of < and <= entirely would also
be fine.
I will always oppose propositions that allow operators like < and <=
to silently return potentially-deceptive values for overlapping intervals.
For example, consider the tactic taken in my own Frink programming
language ( http://futureboy.us/frinkdocs/ ) which allows intervals. I
allow the use of the operators < and <= to be used on intervals *only if
the intervals are non-overlapping.* If the intervals are overlapping,
this produces a run-time error and directs the user to write their
program in an unambiguous, non-surprising fashion by selecting whether
they mean one of the "possibly-" or "certainly-less-than" comparison
operators. (e.g. PEQ, PLT, PLE, CLT, CLE, etc.)
Any final standard should have these possibly- and certainly-
operators, and that is what the user should primarily be using, and not
expecting overloaded < and <= to guess the variant that they mean.
--
Alan Eliasen
eliasen@xxxxxxxxxxxxxx
http://futureboy.us/