P1788: Motions 40 & 41 PASS
P1788,
Motion 40 Introductory Text 1.7, 1.8 - PASSES. Yes - 44; No - 0. Required to pass: 35 (2/3)
Motion 41 (Introductory Text) Clause 2 - PASSES. Yes - 41; No - 3. Required to pass: 35 (2/3)
Reasons for "NO" votes are summarized below
Reminder:
M42 Decoration System - Voting closes Saturiday, February 9
Current tally:
Motion 42 - Decoration System: Yes - 14; No - 1; Needed for quorum - 23 (rules for position papers). Voting ends Saturday, Feb. 9. PLEASE VOTE.
> Please note that Motion 42 consists of TWO PARTS, accessible from the link "Decoration System" and the link "Details." We are voting on BOTH.
>
> Note, however, that we have already voted on "flavors," so you just need to pay attention to Section 6 in the "Decoration System" part.
Remember that if you miss two consecutive votes (these are considered three votes), you are removed from the status of Voting Member, although reinstatement is easy. That is why the number needed for a quorum on Motion 42 has gone down.
George Corliss
P1788 Voting Tabulator
Begin forwarded message:
> From: "Nathan T. Hayes" <nh@xxxxxxxxxxxxxxxxx>
> Subject: Motion 42: NO
> Date: January 22, 2013 3:08:34 PM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <nh@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 42.
>
> There are several reasons I vote NO:
>
> -- Against the intent of Motion 8, the Motion 42 doesn't provide
> decorated interpretations of Empty such as (Empty,DEF), (Empty,DAC). For
> example, section 8.8.7 says decorated intersection operation may provide a
> decoration min(dx,dy), where dx and dy are the decorations of the input
> operands. So this gives:
>
> ([1,2],dac) intersect ([3,4],dac)
> = ([1,2] intersect [3,4],min(dac,dac))
> = (Empty,dac)
>
> But by section 8.8.4 the empty set is not permitted to be decorated with
> decoration dac, so the specification allows implementations that give
> contradictory results.
>
> -- I believe everyone agrees Empty is a set. But if Empty is also an
> interval, then to call (Empty,ILL) a "decorated interval" on the one hand
> and "not an interval" on the other hand doesn't make any sense to me (it is
> a contradiction);
>
> -- The ILL decoration may require strong Computer Algebra System
> (CAS) to prove; and even if such CAS is available, the ILL decoration may
> not always be provable. I think this decoration is unnecessary, too complex
> and should be dropped;
>
> -- Since Motion 42 does not allow Empty to be decorated with
> decorations such as DEF and DAC, the motion must define these bare
> decorations as the compressed decorated intervals (Entire,DEF) and
> (Entire,DAC) respectively. This leads to what in my view is a very buggy
> compressed interval arithmetic system that may return false positives and
> strange, unexpected results. I would warn people not to trust it. For
> example, suppose the user specifies the threshold level such that any
> operation that is not defined and continuous is considered to be an error:
>
> [1,2] \subseteq floor([0,6])
> = [1,2] \subseteq ([0,6],DEF) // Full decorated
> result
> = [1,2] \subseteq DEF // compress non-DAC result
> = [1,2] \subseteq Entire // promote bare decoration
> DEF to Entire
> = true
>
> This is misleading because [1,2] is not a subset of any defined and
> continuous range of floor([0,6]). It would be much better to have bare
> decorations promote to Empty instead of Entire:
>
> [1,2] \subseteq floor([0,6])
> = [1,2] \subseteq ([0,6],DEF) // Full decorated
> result
> = [1,2] \subseteq DEF // compress non-DAC result
> = [1,2] \subseteq Empty // promote bare decoration
> DEF to Empty
> = false
>
> But section 8.8.4 does not allow this. More serious containment violations
> may also occur with the Motion 42 scheme:
>
> [1,2] \subseteq floor([5,6])
> = [1,2] \subseteq ([5,6],DEF) // Full decorated
> result
> = [1,2] \subseteq DEF // compress non-DAC result
> = [1,2] \subseteq Entire // promote bare decoration
> DEF to Entire
> = true
>
> This is a false positive, since [1,2] is not a subset of [5,6] regardless if
> [5,6] is defined and continuous or not.
>
> -- I understand compressed interval arithmetic was removed from
> Motion 42, but it appears these problems will remain when we do get to it.
>
> -- Decoration system with EIN that gives containment order
>
> EIN \subseteq DAC \subseteq DEF \subseteq GAP \supseteq NDF
> \supseteq EIN
>
> fixes most of the troubles listed above, yet such amendment was not made. I
> would likely have voted YES if it had been.
>
> Nate
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motion M0041 NO
> Date: January 24, 2013 9:40:58 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote NO on Motion 41.
>
> In §2.1, 3rd line, it seems to be only about "continuous problems",
> while the main theorem, the FTIA, is not about continuity.
>
> In §2.5 (Decorations):
>
> * "The IEEE 754 model of global flags" -> These are not global flags,
> but status flags. They don't have to be global.
>
> * I would remove "in an era of massively parallel processing".
> Many users don't use such systems. This would make the standard
> more targeted at some users, which is bad.
>
> * "tagged with a few bits" is about Level 4. This should be rephrased
> to be encoding-independent (e.g. in some languages, the concept of
> bits may be non-existent).
>
> * About the 17-byte problem: it should be made clear that this
> is just an example (perhaps the most common case, but still an
> example). Also, one could still think that vector systems may
> be able to pack their data efficiently (e.g. in a vector, by
> grouping the decorations).
>
> Editorial:
>
> In §2.2, 1st line, "IEEE" is missing before "754-2008".
>
> In various places, "level(s)" should be changed to "Level(s)".
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Begin forwarded message:
> From: Jean-Michel Muller <Jean-Michel.Muller@xxxxxxxxxxx>
> Subject: Motion M0041 NO
> Date: January 25, 2013 4:18:27 AM CST
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Dear all,
>
> I vote NO on Motion M0041.
>
> I share Vincent's concerns, and I am ready to vote YES if the changes suggested by Vincent are made.
>
> Best regards
>
> Jean-Michel
> --
> Jean-Michel Muller, directeur de recherches CNRS
> Lab. LIP, ENS Lyon, 46 allée d'Italie, 69364 Lyon Cedex 07, France
> Phone (+33) 4 72728229 - Fax (+33) 4 72728806
> Jean-Michel.Muller@xxxxxxxxxxx http://perso.ens-lyon.fr/jean-michel.muller