RE: Motion P1788/M0013.04 Comparison Operations: NO
In this case, I change to YES, while preserving all my reservations
-----Original Message-----
From: Jürgen Wolff von Gudenberg [mailto:wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, October 08, 2010 10:18 AM
To: William Edmonson; eliasen@xxxxxxxxxxxxxx; Kreinovich, Vladik
Cc: stds-1788
Subject: Re: Motion P1788/M0013.04 Comparison Operations: NO
Alan, Vladik, William
I like to remind you that motion 13.04 is on functionality not on
wording. So if you agree with the set of comparisons suggested by the
motion you should vote YES. The specific wording and naming actions are
to be discussed later.
regards
Jürgen
William Edmonson schrieb:
> 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/
--
-
o Prof. Dr. J. Wolff v. Gudenberg, Informatik II
/ \ Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o Tel.: +49 931 / 31 86602
/ \ Uni E-Mail: wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx
o o Wuerzburg