Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

P1788: Motion M0013.04 Comparison Relations PASSES



P1788,

Motion M0013.04 Comparison Relations PASSES
Yes - 34; No - 5: Quorum: 38 (1/2 of Voting Members)
Quorum has increased from 37 to 38 because we have added two new Voting Members

Baker's call to vote is appended below.

Reasons for NO votes are appended below that.  I have NOT attempted to capture all the discussions.

George Corliss
P1788 Voting Tabulator

Begin forwarded message:

> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Date: September 17, 2010 9:07:12 PM CDT
> Subject: Motion P1788/M0013.04:Comparison_Relations voting period begins
> 
> P-1788:
> 
> 
> The voting period for this motion herewith begins, and will continue
> until after Friday, October 8, 2010.
> 
> Juergen: Please post the PDF and associated information on the web site.
> 
> William: Please record this action in the minutes.
> 
> Sincerely,
> 
> Baker (acting as chair, P-1788)
> 
> ---------------------------------------------------------------
> R. Baker Kearfott,    rbk@xxxxxxxxxxxxx   (337) 482-5346 (fax)
> (337) 482-5270 (work)                     (337) 993-1827 (home)
> URL: http://interval.louisiana.edu/kearfott.html
> Department of Mathematics, University of Louisiana at Lafayette
> (Room 217 Maxim D. Doucet Hall, 1403 Johnston Street)
> Box 4-1010, Lafayette, LA 70504-1010, USA
> ---------------------------------------------------------------
> 
> 

Attachment: CompRel4.pdf
Description: CompRel4.pdf




Begin forwarded message:

> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Date: October 7, 2010 10:49:40 PM CDT
> Subject: Motion P1788/M0013.04 Comparison Operations: NO
> 
>   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/




Begin forwarded message:

> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Date: October 7, 2010 10:58:58 PM CDT
> Subject: RE: Motion P1788/M0013.04 Comparison Operations: NO
> 
> An excellent point, I agree, i.e., I vote NO with a similar explanation. 



Begin forwarded message:

> From: William Edmonson <wwedmons@xxxxxxxx>
> Date: October 8, 2010 7:22:49 AM CDT
> Subject: Re: Motion P1788/M0013.04 Comparison Operations: NO
> 
> I vote NO on the motion for the stated reasons below.
> 
> William Edmonson




Begin forwarded message:

> From: Dominique Lohez <dominique.lohez@xxxxxxx>
> Date: October 8, 2010 11:16:14 AM CDT
> Subject: P1788 Motion 13.4
> 
> My vote is NO
> I may vote YES if the  precede and touch relation  were removed or reffined
> Dominique
> 
> -- 
> Dr Dominique LOHEZ



Begin forwarded message:

> From: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Date: October 8, 2010 11:17:35 AM CDT
> 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




Begin forwarded message:

> From: "Kreinovich, Vladik" <vladik@xxxxxxxx>
> Date: October 8, 2010 11:22:07 AM CDT
> Subject: RE: Motion P1788/M0013.04 Comparison Operations: NO
> 
> In this case, I change to YES, while preserving all my reservations 



Begin forwarded message:

> From: William Edmonson <wwedmons@xxxxxxxx>
> Date: October 8, 2010 1:06:11 PM CDT
> Subject: Re: Motion P1788/M0013.04 Comparison Operations: NO
> 
> As do I. I change mine to yes



Begin forwarded message:

> From: Gabriel Dos Reis <gdr@xxxxxxxxxxxxxxxxxxxxxxxx>
> Date: October 8, 2010 6:16:25 PM CDT
> Subject: Re: Motion P1788/M0013.04 Comparison Operations: YES
> 
> my vote is a qualified YES.
> 
> -- Gaby



Begin forwarded message:

> From: Ian McIntosh <ianm@xxxxxxxxxx>
> Date: October 8, 2010 10:23:00 PM CDT
> Subject: Motion P1788/M0013.04 Comparison Operations: YES
> 
> I vote YES on Motion 13.4.
> 
> I have some concern that users may be confused between Less than and Precedes, but that does not affect the usefulness of the operations. We should think later about whether other names might be better.
> 
> - Ian McIntosh IBM Canada Lab Compiler Back End Support and Development




Begin forwarded message:

> From: "Hossam A. H. Fahmy" <hfahmy@xxxxxxxxxxxxxxxxxxxxxxx>
> Date: October 9, 2010 5:52:08 AM CDT
> Subject: Vote on comparisons
> 
> Dear George,
> 
> If this reaches you while you can still count it, I vote YES on motion 13 "Comparison relations" of Ulrich Kulisch
> 
> On the other hand, I vote NO on the framework motion of Dominique Lohez for the same reasons as others: it is a nice mathematical framework but I see it as a complex idea to include in a standard targeting coherent application among hardware vendors.
> 
> 
> On both motions I note that we might need to discuss the possibility of including "unordered" comparisons if 1788 ends up having Not-an-Interval similar to what 754 has for NaNs.
> 
> Hossam