[Bug libstdc++/20758] operator-(const T&, const complex<T>&) vs operator-(const complex<T>&, const complex<T>&)
kreckel at ginac dot de
Sun Apr 24 22:49:00 GMT 2005
------- Additional Comments From kreckel at ginac dot de 2005-04-24 22:49 -------
(In reply to comment #22)
> BTW, I can't find my copy of Kahan's old "Much Ado..." paper. Does anyone know
> of a downloadable copy? I tried to google for it, but had no luck.
I finally got hold of that paper. Here is an interesting passage:
: the expression z + 1 should not be replaced by the ostensibly equivalent
: z + (1+i0) lest the sign of zero in the imaginary part of z be reversed
: wrongly. ( Generally, mixed-mode arithmetic combining real and complex
: variables should be performed directly, not by first coercing the real to
: complex, lest the sign of zero be rendered uninformative; [...])
It is true, that if z=(zr,zi), then z+1 is different from z+(1,0). The latter
is transformed to (zr+1,zi+0). If zi=-0, the sign in the result is "reversed
The situation is no different for 1+z. In the case z-1 it doesn't really matter
whether the 1 is coerced to complex or not; the result is the same.
Our case 1-z is slightly differnt, though:
1-(zr,zi) = (1-zr,-zi), according to LIA-3
(1,0)-(zr,zi) = (1-zr,0-zi), imaginary part may never become -0.
Conceptually, in this case we don't loose sign information by coercing 1 to
complex prior to subtracting. Rather, we avoid a spurious minus sign, right?
The LIA-3 choice doesn't even serve the purpose of preserving 1-z==-(z-1),
because zr might become 1.0. Sigh.
But this is all a consequence of the arbitrary choice of having only +0 and -0
without a concept of exact zero or undetermined sign of zero. More generally, I
completely fail to understand how one can start worrying about
f(conj(z))==conj(f(z)) when one is willing to permit f(z1)!=f(z2) even though
z1==z2. Somebody pass me that crack pipe, please!
Someone should either close this bug or file one against LIA-3. :-(
More information about the Gcc-bugs