| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
P1788,
Motion 18.01 Trits to Tetris PASSES
Yes - 37; No - 4: Quorum: 37 (1/2 of Voting Members)
Baker's call to vote is appended below.
George Corliss
P1788 Voting Tabulator
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Date: June 17, 2010 2:07:51 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0018.01:TritsToTetrits: Voting period begins
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> P-1788:
>
> The voting period herewith begins for Motion 18. The rules are those for
> a position paper. Voting will continue until after the end of
> Thursday, July 8.
>
> As always, text of the motion is available at
>
> http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
>
> As always, please contact me if you need a password for this web area.
>
> Juergen: Please update the status of this motion on the web page.
> William: Please record this in the minutes.
>
> Best regards,
>
> Baker
I have attached Nate's position paper and a position paper from John Pryce.
===============================================
I collect reasons for NO votes and other comments during the voting period, hoping to facilitate greater consensus as our work continues.
It is my understanding that a vote is not the final word, but a step along the way. I hope that as this issue is constructed into standard wording, the reservations expressed below are given careful consideration.
Begin forwarded message:
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Date: June 28, 2010 12:18:35 AM CDT
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788 Motion 18: No, and revised "stickiness" paper
>
> P1788
>
> I have revised my position paper "Decoration properties, structural induction, and stickiness" following discussions with Nate Hayes and others, and version 3 is attached.
>
> The wording of motion 18 is
>> In particular, I move that P1788 shall:
>>
>> -- adopt the general Level 1 and Level 2 definitions of a tetrit --
>> along with the propagation rules for tetrits in the P1788 exception handling
>> mechanism -- as outlined in Sections 2.1 and 2.2, respectively.
>>
>> -- adopt the specific Level 1 and Level 2 defintions of a "domain"
>> tetrit as outlined in Sections 2.1.1 and 2.2.1, respectively, and require
>> that all P1788 decorations must include such a "domain" tetrit.
>
> As explained in the paper
>
> - I am unhappy with some aspects of Nate's scheme for the "domain" tetrit.
>
> - I think we should neither require all decoration properties to be tetrits, nor define a standard propagation mechanism. At this stage bits, trits, tetrits, ... should all be acceptable, and considered on their merits.
>
> In the schemes for "illformed", "domain", "discontinuous" described in my paper, it happens that all properties are, or decompose to, to independent bits.
>
> Hence I vote No on the motion as worded above. I intend to submit a motion based on my paper, shortly. It will propose four bits in total, leaving plenty of room in a byte for some more...
>
> Regards
>
> John Pryce
Begin forwarded message:
> From: John Pryce <prycejd1@xxxxxxxxxxxxx>
> Date: July 8, 2010 8:20:55 AM CDT
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: P1788 Motion 18: changing to Yes
>
> P1788
>
> Thinking over motion 18 I am changing my vote to Yes. This does not mean I have changed my view on the Hayes "domain" tetrit, but I have to take account that the motion says:
>> Please note, this motion specifically is NOT meant to take a position on:
>>
>> -- a decision to include or exclude any decoration attribute other than
>> the required (by this motion) "domain" attribute
>>
>> -- a decision to allow or prevent any other decoration attribute to be
>> defined in terms of something other than a tetrit
>>
>> The sole purpose of the present motion is to nail down Level 1 and Level 2
>> definitions of a tetrit and to require these semantics are applied to a
>> "domain" attribute that shall be part of the standard for all decorations.
>
> I believe Nate will find, in the fulness of time, that his tetrit does not do "what it says on the tin". That it is not possible for his four states to be both consistently and usefully ordered from "best" to "worst" as in his scheme. That he is trying to pack more than two bits worth of information in two bits.
>
> Whereas, I am convinced by the mathematics in my paper "Decoration properties, structural induction, and stickiness" that my two independent "domain" bits plus one "invalid" bit plus one "discontinuous" bit do what they say on the tin.
>
> But, we have chosen to have decorations, and I believe it is a good choice for which we should be grateful to Nate. And a decoration will be, at the absolute minimum, a byte long in most implementations.
>
> So there's room for Nate's two-bit tetrit, and my four bits, with a couple of bits left over for whatever else we may find desirable in due course.
>
> I have only had a few comments on my paper so far, so I take the liberty of re-sending it.
>
> Regards
>
> John Pryce
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: July 8, 2010 1:29:21 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M00018.01:TritsToTetrits: NO
>
> I vote NO because I believe the issue of dependency among arguments
> in a composition of functions has not been sufficiently addressed.
>
> (I'm sorry that I didn't address this earlier, during the discussion
> period -- but that fell during my vacation, and after that the motion
> had dropped off my radar...)
>
> The reasoning behind the "infimum of ranked tetrits" rule assumes
> that the existential quantifications over the input arguments of
> a multiple-argument function are independent.
>
> The way the propagation rule is specified leaves out the possibility
> of taking dependencies into account.
>
> Consider the function min(x, 1/x**2) evaluated over [-2,+2].
>
> The undefinedness of 1/x**2 at zero is covered up by the min()
> operation, so that it does not matter.
>
> A similar situation arises in case-based programming, where the
> computation is deliberately arranged to avoid domain errors in
> certain cases. Optimistic out-of-order execution may in fact
> trigger exceptions on mispredicted paths, but the system is
> supposed to defer exception reporting until paths are confirmed,
> and have the capability of squashing mispredicted exceptions.
>
> What I am missing in the Trits-to-Tetrits paper is a statement that
> covers such situations, and that permits a case-based implementation
> of functions such as min(x,1/x**2) that avoids reporting a domain
> error.
>
> Michel.
> ---Sent: 2010-07-08 18:54:46 UTC
Begin forwarded message:
> From: "G. William (Bill) Walster" <bill@xxxxxxxxxxx>
> Date: July 8, 2010 10:38:27 PM CDT
> To: Michel Hack <hack@xxxxxxxxxxxxxx>
> Cc: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M00018.01:TritsToTetrits: NO
>
> Excellent point, Michel.
>
> I vote no as well.
>
> Bill
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: July 9, 2010 3:59:18 AM CDT
> To: <stds-1788@xxxxxxxx>
> Subject: Motion P1788/M00018.01:TritsToTetrits: NO
>
> I vote NO on Motion P1788/M00018.01:TritsToTetrits because it suffers
> from an obvious contradiction (though one needs to read the paper
> carefully). My vote would be changed to YES if this is addressed.
>
> Page 2, 4th line, it is said:
>
> a tetrit will be (F,F) if and only if X is empty
>
> but under 3.1.2, one has examples with other tetrits for the empty
> interval. The only thing one can say is that if a tetrit is (F,F),
> then X is empty. Note: one needs to be very careful when defining
> functions (like union and intersection) that are not interval
> extensions of a real function; but if the inf rule is used, the
> above property will be guaranteed.
>
> Other minor problems:
>
> Page 2, last line: no operation -> no operation*s*
>
> Page 3, last line of Definition 1: one could use only one "inf".
>
> Page 5, table of Section 3.1.1, for priority 0, it {Empty} should
> be replaced by Empty (where Empty is the empty set symbol).
>
> --
> 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 / Arénaire project (LIP, ENS-Lyon)
Attachment:
100528Tetrits.pdf
Description: 100528Tetrits.pdf
Attachment:
JDPstickydefsV3.pdf
Description: JDPstickydefsV3.pdf