Motion P1788/M0017.01:IO: PASSES
P1788,
Motion P1788/M0017.01:IO: passes
Yes - 38; No - 2; Quorum: 37 (1/2 of Voting Members)
Baker's call:
You can obtain details about this motion, as well as a PDF of the motion itself, from the web page at
http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
===============================================
I collect reasons for NO votes and other comments during the voting period, hoping to facilitate greater consensus as our work continues.
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: June 26, 2010 11:52:31 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0017.03:IO: YES
>
> My vote is YES.
>
> (This is for version 3 of the document, JDP_IO_ProposalV2.pdf of May 18,
> the one that mentions recovery-conversion.)
>
> Michel.
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: June 27, 2010 12:55:28 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0017.02:IO: NO
>
> I changed my vote from YES to NO, because I just found out
> that what was up for vote was version 2, not version 3.
> (The vote call was actually for version 1, but the version
> posted on grouper.ieee.org/groups/1788/private/Motions is
> JDP_IO_Proposalv2.pdf, i.e. version 2.)
>
> I would change my vote back to YES if the notion of recovery
> conversion was included, as described in JDP_IO_Proposalv3.pdf
> of May 18.
>
> Looking at my e-mail I see the source of the confusion: John
> Pryce had sent me version 3 for comments, but I went on vacation
> before the discussion was deemed complete. The main point (the
> usefulness of "recovery conversion") was not in doubt, but I had
> veered off on a tangent pointing out that recovery conversion was
> possible via either decimal or hexadecimal formats.
>
> Michel.
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: June 27, 2010 1:42:19 PM CDT
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0017.02:IO
>
> Michel, P1788
>
> On 27 Jun 2010, at 18:55, Michel Hack wrote:
>> I changed my vote from YES to NO, because I just found out
>> that what was up for vote was version 2, not version 3.
>
> I'm glad you spotted this. I believe the attached is version 3 that I sent Michel for comments. It is the version on which I wish voting to be conducted.
>
> Michel, please check. In particular note "binary" on the first line of 3.4.3. I think you wanted it removed but I remain totally sceptical of that.
>
> Everyone else, please compare with the previous version and see if they affect your vote.
>
> John
Begin forwarded message:
> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Date: June 27, 2010 2:32:59 PM CDT
> To: John Pryce <j.d.pryce@xxxxxxxxxxxx>, P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0017.02:IO
>
> P1788,
>
> Motion 17.01 (that is the correct version of the motion) is on the text of John's version 2 (attached). That is the version posted on the web site http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html to which Baker's call for voting pointed.
>
> In my role as unofficial parliamentarian, I suggest that it is not appropriate to change what is being voted upon during the voting period, and ESPECIALLY on the last day, and ESPECIALLY^2 on a weekend.
>
> If you wish changing one's vote IS PERMITTED. Simply vote again. I count the LAST vote you cast before voting ends. I have interpreted that voting ends on 2010-6-27 at the time when 2010-6-27 disappears from the face of the earth, which I suppose is 2010-06-28 12:00 GMT +- 1 hour.
>
> I suggest that whether Motion 17 passes or not, John may wish to submit a revised version, and we discuss and vote again.
>
> George Corliss,
> P1788 Voting Tabulator
Begin forwarded message:
> From: Alan Eliasen <eliasen@xxxxxxxxxxxxxx>
> Date: June 28, 2010 1:37:26 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0017:IO: NO
>
> My vote is NO.
>
> It appears that there is confusion as to what text we're even voting
> on, and what members have read. The typos and errors in the motion
> should be fixed, the motion should be withdrawn or considered
> non-binding, and should be re-submitted as a new motion.
>
> It would help if a "diff" of the two proposals was submitted so that
> members don't have to scrutinize it character-by-character for a second
> time.
>
> --
> Alan Eliasen
> eliasen@xxxxxxxxxxxxxx
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: June 28, 2010 3:58:38 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Motion P1788/M0017.02: Yes
>
> I vote YES on Motion 17 (Version 2).
>
> But some obvious typos need to be fixed:
> * 3.1.3: A text-interval is *a* particular kind... (the "a" is missing)
> * 3.3.1: The statement is:
> Y = intvl2text(x,"%.5e");
> but the examples are: 3.33333E-1 and 6.66667E-1. The case doesn't
> match. Use either
> Y = intvl2text(x,"%.5E");
> or
> 3.33333e-1 and 6.66667e-1.
> * 3.4.1: I suppose that %e.d and %f.d should be: %.de and %.df
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Date: June 28, 2010 4:19:21 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0017.02:IO
>
> On 2010-06-27 15:43:00 -0400, Michel Hack wrote:
>> However, my point to John had been that, just as binary intervals can be
>> recovered exactly from decimal text via recovery conversion, it is possible
>> to recover decimal intervals exactly from hexadecimal text, even though
>> the actual hexadecimal representation is not exact. (It must of course
>> have sufficient precision, which means that the current definition of
>> the C format specifier %a, which implies a fixed precision, is inadequate.
>> See the P.S. for more on that.)
>
> I disagree because...
>
> [...]
>> P.S. Hexadecimal recovery conversion for decimal formats.
>>
>> This function might be subsumed by regular convertToTextInterval()
>> in languages/environments that support a "recoverableHex" conversion
>> specifier. The C %a format does not permit a precision specifier, so
> [...]
>
> A precision specifier is permitted for %a:
>
> -- An optional precision that gives the minimum number of digits
> to appear for the d, i, o, u, x, and X conversions, the number
> of digits to appear after the decimal-point character for a, A,
> e, E, f, and F conversions, the maximum number of significant
> digits for the g and G conversions, or the maximum number of
> bytes to be written for s conversions. The precision takes the
> form of a period (.) followed either by an asterisk * (described
> later) or by an optional decimal integer; if only the period is
> specified, the precision is taken as zero. If a precision appears
> with any other conversion specifier, the behavior is undefined.
>
> (from WG14/N1256, i.e. with TC3), but the first digit is not
> uniquely specified, so that one may have to choose more precision
> than really necessary.
>
>> it must always pick the appropriate one, namely %.13a for binary64
>> and %.28a for binary128. C does not have a definition for %a when
>> appplied to DFP input, as it is defined strictly from the binary
>> representation (it must start with '0x1.' for normal and '0x0.' for
>> subnormal numbers).
>
> C doesn't support DFP yet, but DFP specification is in the WG14/N1312
> draft (and this includes changes to %a).
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: June 28, 2010 6:02:32 AM CDT
> To: P1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0017.02:IO
>
> Michel, P1788
>
> On 27 Jun 2010, at 20:43, Michel Hack wrote:
>> Given the (new) requirement for recovery conversion (3.4.2), the need for
>> exact hexadecimal conversion of 3.4.3 actually goes away. It can still be
>> useful, especially for binary formats, but should it be required?
>
> I would prefer not to make it mandatory, i.e. leave the text as it is, if that's OK with Michel. I accept such a feature would be used by some, but by far fewer IMO than those who would use the other features in the document.
>
> John
Begin forwarded message:
> From: Michel Hack <hack@xxxxxxxxxxxxxx>
> Date: June 28, 2010 8:57:08 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Motion P1788/M0017.02:IO
>
> John Pryce wrote:
>> On 27 Jun 2010, at 20:43, Michel Hack wrote:
>>> Given the (new) requirement for recovery conversion (3.4.2), the need for
>>> exact hexadecimal conversion of 3.4.3 actually goes away. It can still be
>>> useful, especially for binary formats, but should it be required?
>>
>> I would prefer not to make it mandatory, i.e. leave the text as it is, ...
>
> The current text of 3.4.3 says "shall" (for binary formats), so that would
> have to be changed to "should", which is fine by me.
>
> Perhaps you meant not to require availability of hex conversion for decimal
> formats. I'll agree to that too, even after Vincent's corrections to my
> claim that C %a was inadequate. The revisions needed to support DFP have
> made the necessary changes to the definition of hex conversion.
>
> While on the subject of minor corrections to JDP_IO_ProposalV3.pdf:
>
> On page 1, last paragraph of section 1, the version history needs
> an update.
>
> Page 3, 1st line of 3.3.1: c/a interval/an interval/
>
> (Thanks, Vincent, for catching a few more.)
>
> Michel.