Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Motion M0045.02: YES -- resend



Michael,

Received, with thanks.

George Corliss

On Jul 29, 2013, at 2:17 PM, Michel Hack <mhack@xxxxxxx> wrote:

> Sorry, I messed up the Message-ID field in my earlier submission of a few
> minutes ago (14:54:06 -0400).  My P.S. also forgot that we are voting on
> actual text after all...
> 
> 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.
> 
> 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
> 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.
>  - For dot and sum, if a NaN is encountered, or if infinities of both signs
>    were encountered in the sum, NaN shall be returned.  ("NaN encountered"
>    includes the case oo*0 for dot.)
>  - For sumAbs and sumSquare, if an Infinity is encountered, +Inf shall be
>    returned.  Otherwise, if a NaN is encountered, NaN shall be returned.
> 
>  (Note that these rules allow for short-circuit evaluation in certain cases.)
> 
>  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.
> 
>  Also, since correct rounding applies, the Inexact flag shall be set unless
>  an exact extended-numeric result is returned.  (If a final overflow or
>  underflow is indicated, the result is inexact.)
> 
> This might still not match a future 754 requirement, which might insist
> that a sum where ALL terms are +0 (or all terms -0) shall preserve the
> sign, regardless of rounding direction.  I find that extra requirement
> to be excessively burdensome as it only applies in extreme cases, and
> I would (if I were a member of the next P754R group) recommend the
> simpler rule -- unless Prof. Kahan convinces us that the complete sign
> rule for pairs must be extended to sums of arbitrary number of terms.
> 
> Michel.
> 
> ---Sent: 2013-07-29 19:30:21 UTC