Re: Motion M0045.02: YES -- resend
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)