P1788: Motion 45 PASSES
P1788,
Motion 45, Exact Dot Product Revision, PASSES.
Yes - 34; No - 8; Required for quorum - 31 (rules for standard text)
42 of our 46 Voting Members voted, and 2 of the others exchanged messages suggesting they were abstaining.
Great participation! THANK YOU.
Voting on Motion 46, Interval Literals, is open until Saturday, 3 August.
Current tally: Yes - 33; No - 1; required for quorum - 23 (rules for position papers)
If you have not voted on Motion 46, PLEASE VOTE
A digest of discussions during the voting are appended below. Note that our Policies and Procedures says that for proposed standard text, votes of "NO" are to be considered as a motion to amend. I leave it to Baker and John to figure out how to apply that.
George Corliss
P1788 Voting Tabulator
Begin forwarded message:
> From: Ralph Baker Kearfott <rbk@xxxxxxxxxxxx>
> Subject: Motion P1788/M0045.02:DotProduct -- voting period begins
> Date: July 8, 2013 2:14:28 PM CDT
> To: <owner-stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: <stds-1788@xxxxxxxxxxxxxxxxx>, Jürgen Wolff v Gudenberg <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Reply-To: <rbk@xxxxxxxxxxxxx>
>
> P-1788:
>
>
> The voting period herewith
> begins. Voting will continue until after Monday, July 29, 2013.
> Since some actual text is proposed, voting on this motion will proceed according to the RULES FOR ACTUAL TEXT. (We are voting on
> 11.11.11 of the document.) That is,
>
>
> Comment can continue during voting, but the motion
> cannot be changed during voting. That is,
>
> 1. a 2/3 majority is necessary for the motion to pass,
>
> 2. any NO votes MUST be accompanied by an explanation of and
> a corresponding commitment to the changes would cause
> the voter to change the "NO" vote to "YES".
>
> Juergen: Please update the web page with this action.
>
> Acting secretary: Please record the transaction in the minutes.
>
> The motion appears in the private area of the IEEE P-1788 site:
>
> http://grouper.ieee.org/groups/1788/private/Motions/AllMotions.html
>
> I have also appended the motion, for your convenience.
>
> As usual, please contact me if you need the password to the private
> area.
>
> Best regards,
>
> Baker (acting as chair, P-1788)
>
> ---------------------------------------------------------------
>
> ======
> 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.
> In an implementation that provides 754-conforming interval types, correctly rounded versions of the four reduction operations sum, dot, sumSquare and sumAbs of IEEE 754-2008 §9.4 shall be provided for the parent formats of each such type. If such correctly rounded operations are provided by the underlying 754 system, these shall be used; otherwise they shall be provided by the implementation.
>
> 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 given as non-integral, zero or negative, 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---
>
>
> --
>
> ---------------------------------------------------------------
> Ralph 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
> ---------------------------------------------------------------
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: Ulrich Kulisch <ulrich.kulisch@xxxxxxx>
> Subject: Motion 45.02
> Date: July 11, 2013 2:36:21 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
> I would vote yes if CA and the EDP would be required instead of just recommended.
>
> The dot product is a fundamental opertation in mathematics as well as in numerical analysis. The reintegration of the EDP into scientific computing is a step that is long overdue. Its realization in hardware and software is straight forward and easy. It is free of exceptions. For interval arithmetic and numerical analysis the EDP is a major brakethrough. The correctly rounded reduction operations can easily be provided via CA and the EDP. It also is the basic operation for dynamic precision real and interval arithmetic. If integrated into the processor it brings a speed up for accumulations comparable to that of an adder tree for multiplications.
>
> A central arithmetic operation should be requested more urgently. I mention once more that the request was supported by the two IFIP letters and at ISC'10.
>
> Ulrich Kulisch
>
>
> --
> Karlsruher Institut für Technologie (KIT)
> Institut für Angewandte und Numerische Mathematik
> D-76128 Karlsruhe, Germany
> Prof. Ulrich Kulisch
>
> Telefon: +49 721 608-42680
> Fax: +49 721 608-46679
> E-Mail:
> ulrich.kulisch@xxxxxxx
> www.kit.edu
> www.math.kit.edu/ianm2/~kulisch/
>
>
> KIT - Universität des Landes Baden-Württemberg
> und nationales Großforschungszentrum in der
> Helmholtz-Gesellschaft
>
Begin forwarded message:
> From: Bo Einarsson <boein@xxxxxxxxx>
> Subject: Motion 45.02 NO
> Date: July 12, 2013 1:23:01 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
> I would vote yes if CA and the EDP would be required instead of just
> recommended.
>
>
> REgards,
>
> Bo
> --
> Bo Einarsson
> Ekholmsvägen 249
> SE-589 29 LINKÖPING
> SWEDEN
> Tel 013 - 151896
Begin forwarded message:
> From: "Neher, Markus (IANM) [IANM bezeichnet die Organisationseinheit Institut für Angewandte und Numerische Mathematik]" <markus.neher@xxxxxxx>
> Subject: Motion 45.02: No
> Date: July 12, 2013 2:00:19 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
>
> I would vote yes if CA and the EDP would be required instead of just recommended.
>
> Regards,
>
> Markus Neher
Begin forwarded message:
> From: Günter Mayer <guenter.mayer@xxxxxxxxxxxxxx>
> Subject: Motion 45.02 -NO.
> Date: July 12, 2013 1:43:27 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
>
> I would vote yes if CA and the EDP would be required instead of just recommended.
>
> Best regards,
>
> Guenter Mayer
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Motion P1788/M0045.02:DotProduct -- YES
> Date: July 12, 2013 3:06:00 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote is YES on Motion 45.02.
>
> It is an improvement. But I would rather see CA out of the standard
> as it is too hardware oriented and until now, processor makers didn't
> show any interest in implementing it. Its efficiency in the context of
> parallelism is also questionable. In such a case, the use of CA should
> be discouraged in favor of other, more efficient methods.
>
> --
> 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: Richard Fateman <fateman@xxxxxxxxx>
> Subject: Re: Motion P1788/M0045.02:DotProduct -- YES
> Date: July 13, 2013 12:09:09 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
> Reply-To: <fateman@xxxxxxxxxxxx>
>
> On 7/12/2013 1:06 AM, Vincent Lefevre wrote:
>> My vote is YES on Motion 45.02.
>>
>> It is an improvement. But I would rather see CA out of the standard...
>
> I would prefer a separate "suggestions for implementation" section.
>
> More specifically for interval arithmetic it seems to me that there are several technologies
> for achieving the same thing as CA, and if the goal is to implement interval arithmetic most
> efficiently or most accurately, then in some languages, there may be better ways.
>
> For example, languages which provide exact (arbitrary precision) rational arithmetic or
> arbitrary precision floats -- each of which is a superset of
> complete arithmetic, may provide better solutions.
>
> Since the arbitrary precision integer or rational number arithmetic is typically arranged
> to grow as needed, short results are better accommodated. Thus to multiply 0.5 by 0.5
> or even 5 by 5 it is hardly efficient to allocate 4288 bits.
>
> What languages already allow for arbitrary integers and rational? There are the GMP libraries
> mpz (integers) and mpq (rationals) that -- although they do not need special hardware-- come
> with special assembler-coded routines for certain architectures or sub-implementations of
> architectures that, in my experience, can provide substantial (10X or more) speedup from
> the same procedures in pure C. Not only do they support the limited cross-product of double-floats,
> but allow multiplication of arbitrary precision rationals directly.
>
> It is also possible to create a similarly limited simulation of CA by using the mpfr library.
> (There is of course mpfi for intervals...)
>
> See
> http://gmplib.org/manual/Language-Bindings.html#Language-Bindings
> for a list of the more than 18 languages, often with multiple implementations
> that offer access to GMP, though some of these may only be for the integer (mpz) library.
>
> Also computer "algebra" languages that offer numerical computation too tend to include
> exact rationals, so Mathematica, Maple, Axiom, Fricas, Reduce, Mathics, Yacas. These all
> make available a superset of CA. Also some of these systems already offer interval
> arithmetic directly, though usually with a few features at odds with requirements currently
> in the proposed standard.
>
> Writing an exact dot product of floats in one of these languages can be quite simple, or
> it can be elaborately "optimized" as in other contexts where floating-point mantissas are split up
> to avoid long multiplications, etc.
>
> As an example of a simple and complete (but not "optimal") program, here's one in lisp:
>
> (defun exactdotproduct(A B)
> (reduce #'+ (map 'list #'(lambda(x y)(* (rational x)(rational y))) A B)))
>
> This program allows the input lists or vectors A B to include any real number types:
> single/double/extended floats, rationals, integers. It converts each number to an exact
> rational, multiplies them in pairs and sums the results to produce a rational number which
> can be converted (with rounding) to any float type. This 2 line program is easy in lisp,
> but that is because there already is a fully supported data type of arbitrary precision
> rational with arithmetic, comparisons, conversions, etc.
>
> So I see the argument against requiring EDP and CA:
>
> * It is not actually required to implement interval arithmetic,
> * It takes extra space in the standard textually as well as intellectually,
> * It requires introduction into the host language of another data type (not an interval).
> * There appears to be nothing that can be done with this data type except to convert
> it (using programs unspecified in the standard....) to one of the float types rounded
> up or down or nearest. Of course more could be done, but the standard document
> would have to be enlarged to incorporate that.
>
> I have no problem with listing CA etc in a section on implementation suggestions.
Begin forwarded message:
> From: Ulrich Kulisch <ulrich.kulisch@xxxxxxx>
> Subject: Re: Motion P1788/M0045.02:DotProduct -- YES
> Date: July 13, 2013 12:27:09 PM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Am 12.07.2013 10:06, schrieb Vincent Lefevre:
>> My vote is YES on Motion 45.02.
>>
>> It is an improvement. But I would rather see CA out of the standard
>> as it is too hardware oriented and until now, processor makers didn't
>> show any interest in implementing it.
>>
> This is certainly not correct. I mentionend in an earlier mail that the EDP was hardware supported in the 1980ies on processrs of the /370 architecture by IBM, Siemens, Hitachi, and others. And I know that today processor makers are at least thinking to realize it.
> IEEE P1788 should support these activities by requiring it.
>
> Best regards
> Ulrich
Begin forwarded message:
> From: Werner Hofschuster <werner.hofschuster@xxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion 45.02: NO
> Date: July 15, 2013 9:48:12 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
>
> I would vote yes if CA and the EDP would be required instead of just recommended.
>
> Best regards,
> Werner Hofschuster
Begin forwarded message:
> From: Richard Fateman <fateman@xxxxxxxxx>
> Subject: Re: P1788: Motions 45 & 46 - Please vote
> Date: July 15, 2013 9:21:59 AM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Reply-To: <fateman@xxxxxxxxxxxx>
>
> Not exactly happy with either but I'll vote yes on both of them.
>
> Richard
>
Begin forwarded message:
> From: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Subject: Re: P1788: Motions 45 & 46 - Please vote
> Date: July 15, 2013 2:21:29 PM CDT
> To: "<fateman@xxxxxxxxxxxx>" <fateman@xxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> Richard,
>
> Received, with thanks.
>
> Would you care to record your reservations?
>
> An advantage of doing so is that your reservations get assembled into the digest of comments during voting I compile at the conclusion of voting. According you our Policies and Procedures, "No" votes are considered ad motions to amend (in some sense), so the comments during voting must be taken seriously.
>
> George Corliss
> P1788 Voting Tabulator
>
>
> On Jul 15, 2013, at 9:21 AM, Richard Fateman <fateman@xxxxxxxxx>
> wrote:
>
>> Not exactly happy with either but I'll vote yes on both of them.
>>
>> Richard
>>
>
Begin forwarded message:
> From: Richard Fateman <fateman@xxxxxxxxx>
> Subject: Re: P1788: Motions 45 & 46 - Please vote
> Date: July 15, 2013 3:32:07 PM CDT
> To: 'stds-1788' <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
> Reply-To: <fateman@xxxxxxxxxxxx>
>
> I sent my votes (yes, yes) to George Corliss, expressing some reservations. He suggested
> I record the reservations. Here they are.
>
> Regarding interval literals, I vote yes in the interest of no longer discussing this matter.
> In reality I feel that the only numbers necessary for defining an interval are those scalar numbers
> that can be expressed in the host language as input and as output. If there are numbers
> that one wishes to express for purposes of defining interval endpoints that cannot be expressed
> (input, output, storage) in the host language except as character strings,
> then that language is simply unsuitable for interval arithmetic.
>
> I would prefer that interval literals and the complications revolving around them simply be
> struck from the standard especially given the complexity of this material.
>
> This does not seem to be a popular opinion, and so my reaction is basically, eh, if you insist that you need it.
>
> I would not use it or implement it.
>
> ............
>
> Regarding exact dot product, there are many pieces of information offered which appear to me
> to be irrelevant, like the fact that it can be implemented in hardware (or not), and is it a good idea for numerical
> computation generally.
>
> The question appears to me to be
>
> Is it something that, absent inclusion in a P1788 standard, would be done in different ways that would cause confusion in the application of interval arithmetic.
>
> I think the answer to that is: NO. So it should not be required. Should it be recommended?
>
> If the implementation of interval arithmetic is conveniently and economically phrased in terms of EDP as
> provided or implemented in the language of the implementation, then implementors would be wise to use it.
> It could be a recommended technique. However, if interval arithmetic is implemented to the same specification but happens not to use EDP, there is no fault, and therefore no need to REQUIRE EDP.
>
> Furthermore, counting against requirement:
>
> adding a functionality which has neither interval inputs nor interval outputs and appears to require
> a data object (extended accumulator) not otherwise present in the standard, seems gratuitous in the
> context of an interval standard.
>
> My vote is to make it NOT required. My preference would be to relegate it to a suggestion for
> implementation technique.
>
>
>
> Richard Fateman
Begin forwarded message:
> From: John Pryce <j.d.pryce@xxxxxxxxxx>
> Subject: Motion P1788/M0045.02:ExactDotProductRevision -- revised text
> Date: July 4, 2013 2:19:40 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> P1788
>
> I submit Motion 45.02 which is a friendly amendment of Motion 45. Changes:
>
> - Dan Zuras (20130605) found Clause 1 a bit ambiguous, so I revised it. I hope this removes the ambiguity.
>
> - I changed the words about "unavoidable overflow" (renamed "intermediate overflow" which is what it is) to require that it be impossible in practice. This shortens the text a bit.
>
> - Vincent Lefevre was unhappy with para. 1 of the proposed text producing a clash between reduction operations possibly provided by an underlying 754 system ("754 reductions"), and those provided by 1788. I think he still dislikes the rewording below, as he says:
>>
>> This is my point: avoid having two versions (at least from two
>> different standards). This would add confusion and difficulties
>> for writers of portable user code. The right solution would be
>> to "fix" the IEEE 754 implementation. Let's recall that it was
>> said that the IEEE 754 intent was to have these operations
>> correctly rounded.
> Yes indeed. But if the implementers of some 754 implementation don't get round to it (it's regarded as low priority, programmer falls under a bus, ...), surely the 1788 implementers should be allowed to provide their own? And write configuration files that ensure the correct versions are used? Experts on implementation, please comment.
>
> I hope recent discussion in the "back to the roots" thread, on the question "who needs highly accurate computation on inexact data?", has convinced the skeptics that the answer is "you do, very much, sometimes" so these operations have an important place in the standard.
>
> I acknowledge that Prof Kulisch will be disappointed by the change that this motion makes, if it passes. But the ineluctable facts are
> - Several experts have argued conclusively that for *software* implementations, CA is not the most efficient algorithm to compute the accurate sums, etc., needed in applications.
> - 1788 is not authorised to require that anything shall be done in hardware. So the fact that CA is efficient in hardware may affect what 1788 states as recommended, but not what it states as required.
>
> Chair, I hope we can proceed to a vote after a few days.
>
> 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.
> In an implementation that provides 754-conforming interval types, correctly rounded versions of the four reduction operations sum, dot, sumSquare and sumAbs of IEEE 754-2008 §9.4 shall be provided for the parent formats of each such type. If such correctly rounded operations are provided by the underlying 754 system, these shall be used; otherwise they shall be provided by the implementation.
>
> 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 given as non-integral, zero or negative, 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: Walter Kraemer <kraemer@xxxxxxxxxxxxxxxxxxxxx>
> Subject: Motion 45.02 NO
> Date: July 23, 2013 12:15:45 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Cc: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> My vote on Motion 45.02 is NO.
>
> I would vote yes if CA and the EDP would be required instead of just recommended.
>
> Regards,
> Walter
Begin forwarded message:
> From: Guillaume Melquiond <guillaume.melquiond@xxxxxxxx>
> Subject: Motion 45: YES
> Date: July 29, 2013 3:52:40 AM CDT
> To: <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on motion 45 DotProduct.
>
> I have mixed feelings about the last sentences though. I feel that any implementation recommendation should be part of an appendix rather than part of the standard. The standard should be more explicit, e.g. "up to 2^40 terms with correct rounding". But this nitpick does not warrant me voting against.
>
> Best regards,
>
> Guillaume
Begin forwarded message:
> From: Svetoslav Markov <smarkov@xxxxxxxxxx>
> Subject: Motion 45.02 NO
> Date: July 29, 2013 3:32:45 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
>
> My vote on Motion 45.02 is NO.
> I would vote yes if CA and the EDP would be required instead of just
> recommended.
>
> S Markov
Begin forwarded message:
> From: Nathan Hayes <nh@xxxxxxxxxxxxxxxxx>
> Subject: RE: P1788 PLEASE VOTE
> Date: July 29, 2013 12:24:51 PM CDT
> To: "Corliss, George" <george.corliss@xxxxxxxxxxxxx>
>
> Hi George,
>
> I vote NO on Motion 45. I found earlier motions on this subject to be compelling. Recent decisions to change seem questionable.
>
> I reluctantly vote YES for Motion 46... idea-wise it is ok but in my view the P1788 decoration system it encodes is broken.
>
> Nate
Begin forwarded message:
> From: Michel Hack <mhack@xxxxxxx>
> Subject: Motion M0045.02: YES
> Date: July 29, 2013 1:54:06 PM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> I vote YES on motion 45, requiring correctly-rounded dot product,
> but only recommending exact dot product (EDP), not requiring it.
>
> I do this with a heavy heart because Complete Arithmetic keeps
> getting short shrift. However, the EDP alone would not help much;
> one would have to specify support of a complete Complete Arithmetic
> package along the lines of VanSnyderP1788.pdf (in our list of position
> papers posted on ieee.grouper.org). Complete Arithmetic deserves its
> own standard, which could be useful in non-interval environments where
> full support of 1788 might be considered too much.
>
> Michel.
>
> P.S. I have already proposed some improved wording about the relation to
> 754-2008 -- but this motion is about the concept and not the text.
> At issue were exactness indications, and the sign of zero.
> ---Sent: 2013-07-29 19:06:44 UTC
Begin forwarded message:
> From: "J. Wolff von Gudenberg" <wolff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
> Subject: motion 45
> Date: July 29, 2013 8:45:17 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> P1788
> I am convinced that CA and the long accumulator are an excellent tool to gain accuracy.
> hence it will make its way, regardless that it only is recommended
>
> my vote is YES
> Jürgen
Begin forwarded message:
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> Subject: Re: Motion M0045.02: YES -- resend
> Date: July 30, 2013 8:53:27 AM CDT
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> On 2013-07-29 15:17:08 -0400, Michel Hack wrote:
>> I do have a nit to pick with the text however, concerning the requirement
>> for an exact zero to be returned as +0. This might clash with a future
>> version of 754 that also requires a correctly-rounded dot product.
>
> I agree with you, but...
>
>> I propose the following revised text:
>>
>> 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
>> direction. An exact zero shall be returned as +0 in all rounding
>> directions, except for roundTowardNegative, where -0 shall be returned.
> [...]
>
> On this point, as I've said in the private discussion, I disagree.
> For the sign of zero, it should follow the IEEE 754 rules (which are
> commutative and associative: this is needed to make sense for
> reduction operations). I think that it is particularly important that
> sum_RN(-0,-0) has the same sign as (-0) +_RN (-0), and that sum_RN(x)
> has the same sign as x. The average cost should be very little[*] (not
> worse than TMD-related problems). This is the only solution to make
> sure that it will not clash with IEEE 754 if it is revised following
> its own rules.
>
> [*] and it would actually be faster in the trivial cases with 1 or 2
> arguments.
>
> Note that for operations where the sign of zero is "not supported",
> +0 is returned in all rounding directions: see log(1) and acos(1).
>
> --
> 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)