Re: Motion P1788/M0013.04 Comparison Operations: NO
I vote NO on the motion for the stated reasons below.
William Edmonson
On Oct 7, 2010, at 11:49 PM, Alan Eliasen wrote:
> 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/