P1788:
Voting is in progress for
Motion 45. Exact Dot Product Revision
Current tally: Yes - 9; No - 4; quorum - 31
Voting extends through Monday, 29 July, 2013
Motion 46. Interval literals
Current tally: Yes - 3; No - 0; quorum - 23
Voting extends through Saturday, 3 August, 2013.
Details of each motion are below.
PLEASE VOTE.
George Corliss
P1788 Voting Tabulator
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Subject: Fwd: Motion P1788/M0045.02:DotProduct -- final text
> Date: July 9, 2013 10:59:24 AM CDT
> To: stds-1788 <STDS-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> -------- Original Message --------
> Subject: Motion P1788/M0045.02:DotProduct -- final text
> Date: Tue, 9 Jul 2013 15:22:25 +0100
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> To: rbk@xxxxxxxxxxxxx
>
>
>
> P1788
> This is the text to be voted on. Webmaster, please put this on the web site. I am happy to keep the rationale as originally written, but of course all subsequent discussion in the group is relevant.
> In response to a nit from someone I changed [vectors whose length] "is given as non-integral, zero or negative" to "is not given as a positive integer". I hope this isn't some dreadful solecism.
> John Pryce
>
> ======
> Motion
> ======
> 1. An implementation of Exact Dot Product EDP and Complete Arithmetic CA be no longer required by P1788. They should be treated as a recommended way to achieve the broader aim of evaluating highly accurate sums and dot products, which has many uses in interval
computing.
>
> 2. The current text on EDP and CA (11.11.11 in the current draft) be moved to Level 3 with minor revisions and replaced at Level 2 by the following text:
>
> ---start of text---
> Reduction operations.
>
> An implementation that provides 754-conforming interval types shall provide the four reduction operations sum, dot, sumSquare and sumAbs of IEEE 754-2008 §9.4, correctly rounded. These shall be provided for the parent formats of each such type.
>
> Correctly rounded means that the returned result is defined as follows.
> - If the exact result is defined as an extended-real number, return this after rounding to the relevant format according to the current rounding mode. An exact zero shall be returned as +0 in all rounding modes.
> - Otherwise return NaN.
>
> All other behavior, such as overflow, underflow, setting of IEEE 754 flags, raising of exceptions, and behavior on vectors whose length is not given as a positive integer, shall be as specified in IEEE 754-2008 §9.4. In particular, evaluation is as if in
exact arithmetic up to the final rounding, with no possibility of intermediate overflow or underflow.
>
> Intermediate overflow could result from adding an extremely large number N of large terms of the same sign. The implementation shall ensure this cannot occur. This is done by providing enough leading carry bits in an accumulator, or equivalent, so that the
N required is unachievable with current hardware. [Note: For example, Complete Arithmetic for IEEE 754 binary64, parameterized as recommended by Kulisch and Snyder, requires around 2^88 terms before overflow can occur.]
>
> It is recommended that these operations be based on an implementation of Complete Arithmetic as specified in §X.Y.
> ---end of text---
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk5287@xxxxxxxxxxxxx>
> Date: July 13, 2013 12:59:24 PM CDT
>
> P-1788:
>
> The voting period for Motion 46 herewith
> begins. Voting will continue until after Saturday, August 3, 2013.
> Voting on this motion will proceed according to the rules for
> position papers (quorum and simple majority).
> Comment can continue during voting, but the motion
> cannot be changed during voting.
>
> I have forwarded the email from our overall technical editor
> with the motion as updated on July 13, 2013. (The motion
> consists of a 2-line statement, a clarification, and a file
> in PDF. The email also contains some explanation of plans
> for a two-tiered standard, and how it might impact this motion.)
>
> Webmaster: Please update the web page as follows:
>
> 1. Please post the updated motion and its clarification.
>
> 2. Please post the corresponding PDF document.
>
> 3. Please update the motion's status.
>
> Acting secretary: Please record the transaction in the minutes.
>
> NOTE: ALTHOUGH THE PDF CONTAINS PAGES FROM THE DRAFT TEXT,
> THIS MOTION IS ON CONTENT, RATHER THAN ACTUAL WORDING.
> IF THIS MOTION PASSES, WE WILL HAVE A SEPARATE VOTE ON THE
> ACTUAL WORDING.
>
> The motion will appear in the private area of the IEEE P-1788 site:
>
>
http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
>
> As usual, please contact me if you need the password to the private
> area.
>
> Best regards,
>
> Baker (acting as chair, P-1788)
>
> ==================================================================
> ==================================================================
>
>
> On 07/13/2013 03:54 AM, John Pryce wrote:
>> Baker, P1788
>>
>> Chair, are we ready to vote?
>>
>> I apologise for having written about this motion "Here is text to vote on", or similar. Well, yes, but motion 46 is not about the actual wording but about the content. (BTW that means it passes on simple majority, not two thirds.)
>>
>> This is important because the motion is in danger of being endlessly bogged down in the debate
>>
>> "Do we want a small, basic standard or a larger, fuller-featured standard?"
>>
>> As it relates to motion 46:
>> - Do we want rational number literals such as "22/7"? NO!! (e.g. Jürgen) YES!! (e.g. Dmitry)
>> - Do we want other number literals to follow (a) the syntax of the host language,
>> or (b) a minimal syntax whose productions are common to all widely used languages?
>> [I started with (b), which was criticised; changed to (a);
>> now there is pressure to go back to (b).]
>> - etc.
>>
>> It seems clear we need both a "full" standard, and a "basic" one that is a subset.
>>
>> We have a willing candidate to be "Technical Editor for the Basic Standard" (TEBS) and I hope we can shortly announce he has accepted the chair's formal invitation. His role is to create the basic subset and, I hope, a simplified document that describes
only that subset. The basic standard will be angled toward ease of implementation.
>>
>> That being so, I ask us to vote on motion 46 concentrating on the principles. Please ignore issues of what details are in or out of the subset: you will have your say on these when the TEBS makes his proposals.
>>
>> ======
>> Motion 46, revision of 13 July 2013.
>> ======
>> The syntax and semantics of interval literals shall be as specified in the attached extract from Draft 7.3.
>>
>> ======
>> Clarification
>> ======
>>
>> - The TEBS will choose a subset to form the definition of interval literals in the basic standard. ("Subset" means any literal that conforms to the basic standard also conforms to the full standard.)
>>
>> - The main principles you are voting on, as I see it, are:
>>
>> 1. Interval literals (ILs) have a mathematical value. Converting
>> them to finite precision intervals is a separate operation.
>>
>> 2. ILs are what the Level 2 constructor text2interval(), of any
>> finite precision type, takes as input.
>>
>> 3. ILs have a close relation to interval I/O: it shall be possible
>> to write an internal interval to an IL, and read an IL to an
>> internal interval, preserving containment in either direction.
>> (Not directly covered by this motion, but relevant.)
>>
>> 4. Inf-sup form "[1.2,3.4]" and uncertain form "12.345?6" are both
>> a Good Thing.
>>
>> - Whether number literals follow the host language syntax or a simple language-independent syntax, is left to the TEBS to decide.
>>
>> ======
>> Notes
>> ======
>> - In the new text I have added a definition of what "last place" (an integer) and "unit in last place" (ulp) mean in this context, since I learned they have more than one meaning and are unfamiliar to some.
>> [Example. For the decimal strings 123 and 123. , as well as 0 and 0. , the last place is 0 and one ulp is 1. For .123 and 0.123 , as well as .000 and 0.000 , the last place is −3 and one ulp is 0.001.]
>>
>> - I hope to have corrected an error in the definition of "exponent field" for uncertain form, which was inconsistent as to whether the prefix character 'e' was included or not.
>>
>> - This was the original version of the motion.
>>> ======
>>> Motion
>>> ======
>>> The syntax and semantics of interval literals shall be
>>> - as specified in Draft 7.1 circulated as 20130402Level1and2textV7.1Sent.pdf;
>>> - with the addition of the singleton interval form [x] which is equivalent to [x,x].
>>>
>>> The standard will not at this stage include a facility for named constants such as pi to be included in the definition of an interval literal.
>
>
> --
>
> ---------------------------------------------------------------
> 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
> ---------------------------------------------------------------
>
>