Re: Motion P1788/M0013.04 Comparison Operations: NO
As do I. I change mine to yes
On Oct 8, 2010, at 12:22 PM, Kreinovich, Vladik wrote:
> 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