| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788, Motion M00 20.01 Comparing Comparisons FAILS for lack of a quorum Yes - 14; No - 20: Quorum: 38 (1/2 of Voting Members) Quorum has increased from 37 to 38 because we have added two new Voting Members. The count changed because on audit, I found I have miss-counted one vote. Under our Policies and Procedures, the Voting Tabulator has the power to extend the voting period for the purpose (only) of obtaining a quorum. While I might consider that for motions that are 1-2 votes short of passing by a large majority, I choose NOT to do that here because it seems clear there is NOT a strong vote in favor, and fail vs. fail to achieve a quorum are similar outcomes. 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:09:11 PM CDT > To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx> > Subject: Motion P1788/0020.01:Comparing_comparisons -- discussion period begins > Reply-To: <rbk@xxxxxxxxxxxxx> > > 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: John Pryce <j.d.pryce@xxxxxxxxxxxx> > Date: September 20, 2010 4:36:11 AM CDT > Subject: M0020.01 Comparing comparisons NO > > I forgot to give my reasons to vote NO on Dominique Lohez's "frameWorkForComparisonRelations" paper. > > As a pure mathematician, I like its contents a lot. As a mathematician trying to do software engineering, I think it goes beyond what anyone writing practical interval software needs. > - Arnold says he only ever needed 3 comparisons. > - Baker concurs, though admitting his applications were similar to Arnold's. > - Someone said the Kulisch <= is used in branch-and-bound to rank candidates: that makes 4. > > No one else has offered evidence of uses in actual interval code. So for sake of KISS I vote against. > > John Pryce Begin forwarded message: > From: "Kreinovich, Vladik" <vladik@xxxxxxxx> > Date: September 20, 2010 9:00:37 AM CDT > Subject: RE: M0020.01 Comparing comparisons NO > > I vote NO, for the same reason. Begin forwarded message: > From: Jürgen Wolff von Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Date: September 22, 2010 8:12:29 AM CDT > Subject: Re: Motion 13.04, Yes, Motion 20 NO > > My vote on Motion 13.04 is: Yes. > My vote on Motion 20 is :NO > Folowing John and vladik, I vote no, > the motion clealy is a nice add-on. Hence it should be optional. > I would vote yes, if all the shall's are changed to should's or may's > > Juergen Begin forwarded message: > From: Marco Nehmeier <nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Date: October 3, 2010 3:54:16 AM CDT > Subject: P1788 M0020.01 NO > > It ist an interesting Motion on a mathematical level but I thing it is far beyond the scope of an interval standard. > So my vote is NO > > Best regards > Marco Begin forwarded message: > From: Michel Hack <hack@xxxxxxxxxxxxxx> > Date: October 3, 2010 3:25:24 PM CDT > Subject: P1788 M0020.01 -- vote NO > > I vote NO on Motion 20.01 -- BRA framework for interval comparisons. > (BRA = Binary Relation Algebra) > > This is a beautiful mathematical arrangement, but in my opinion it > belongs in the 1788 standard as a Mona Lisa reproduction would fit > in an Algebra textbook. > > (Minor beauty blemish, btw: The definition of atomic relations (middle > of page 3 of the Lohez paper) should say "for any *distinct* i and j".) > > It might also have been useful if one or two useful examples of BRA > generator sets had been presented, instead of just deferring the choice > to a future motion -- though I don't think it would have swayed my vote. > > I actually have some sympathy for the "IntervalComparison" datatype and > the operations defined on it -- but I would (a) keep it as a generic BRA > type (applicable to comparisons, but to other relations as well), and > (b) have it available as a separate package. I just don't think P1788 > is the place for it, except as a reference in a programming note. > > Michel. > ---Sent: 2010-10-03 20:49:17 UTC Begin forwarded message: > From: Stefan Siegel <St.Siegel@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Date: October 5, 2010 5:47:08 AM CDT > Subject: P1788 M0020.01 NO > > My Vote is NO. > > As Marco remarked: It's interesting on a mathematical level but it's far beyound the scope of an interval standard. > > Best regards > Stefan Begin forwarded message: > From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx> > Date: October 7, 2010 11:53:41 AM CDT > Subject: P1788 Motion 20.01: NO > > The motion presents an interesting approach. But without an actual BRA > to instantiate it, it just seems to be overengineering things. While it > may be good to keep this algebraic setting in mind for future works (and > to flesh out the standard), I feel the proposal is itself out of the > scope of the standard at the current time. > > So I vote NO on motion 20.01. > > Best regards, > Guillaume Begin forwarded message: > From: Mark Stadtherr <markst@xxxxxx> > Date: October 7, 2010 1:08:24 PM CDT > Subject: P1788 Motion 20.01: NO > > I will vote NO on motion 20.01 for reasons others have stated. > I anticipate further discussion on this topic. > > Mark Begin forwarded message: > From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx> > Date: October 8, 2010 2:46:35 AM CDT > Subject: Motion P1788/M0020.01 Comparison Relations: NO > > My vote on M0020.01 is NO. > > This paper is a nice piece of mathematical foundation and background > for further discussions. However, I do not believe that it is concrete > enough to warrant its inclusion into the standard at this time. > > When voting "NO", we are required to state what would be required to > vote "YES". This is somewhat difficult in this case. I think a more > concrete proposal, including a specific choice of required algebraic > operations, would be necessary. Other competing motions currently cover > a simple set of required binary comparisons, and may be preferred. > > -- > Alan Eliasen > eliasen@xxxxxxxxxxxxxx > http://futureboy.us/ Begin forwarded message: > From: Ian McIntosh <ianm@xxxxxxxxxx> > Date: October 8, 2010 10:34:37 PM CDT > To: <stds-1788@xxxxxxxxxxxxxxxxx> > Subject: Motion P1788/M0020 Binary Relations Algebra: NO > > I vote NO on Motion 20. > > I have seen similar ideas useful in dealing with the far simpler comparisons for floating point, integers and character strings, so I agree that this is useful. I appreciate it and I'm not opposed to it, but so far I don't think it needs to be part of the standard. > > I would change my vote to yes if comparisons continue to be controversial, on the grounds that in that case we ourselves need a better way to think about them. > > - 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