[Bug libstdc++/20758] operator-(const T&, const complex<T>&) vs operator-(const complex<T>&, const complex<T>&)

kreckel at ginac dot de gcc-bugzilla@gcc.gnu.org
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 mailing list