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

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

[kreckel at ginac dot de]

Here are three ways to express complex<double>(-4.,0.):

    // complex<double> operator-<double>(const double&, const complex<double>&)
    complex<double> a1 = 1.
	               - complex<double>(5.0, 0.0);
    cout << a1 << endl;  // (-4,-0)
    // complex<double> operator-<double>(const complex<double>&, const
complex<double>&)
    complex<double> a2 = complex<double>(1.0, 0.0)
	               - complex<double>(5.0, 0.0);
    cout << a2 << endl;  // (-4,0)
    // complex<double> operator-<double>(const complex<double>&, const double&)
    complex<double> a3 = complex<double>(1.0, 0.0)
                       - 5.0;
    cout << a3 << endl;  // (-4,0)

In the first version, the imaginary part gets a spurious minus sign.  That is
quite disruptive when you consider that a1 could be the argument of a logarithm
because it then ends up on the wrong side of the branch cut.

While I am currently unable to track this to any standard, I would guess that
the resulting imaginary part should be governed by what 0.0-0.0 is.  By analogy,
the first result would be wrong, unless its undefined behavior (which would be a
pity).

The problem is in libstdc++-v3/include/std/std_complex.h:366.  I propose to
change the function body to not use unary operator- in the imaginary part.  I'm
going to attach two analogous patches.

-- 
           Summary: operator-(const T&, const complex<T>&) vs operator-
                    (const complex<T>&, const complex<T>&)
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: kreckel at ginac dot de
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-04 21:39 -------
Created an attachment (id=8531)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8531&action=view)
Avoid using operator-, version 1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-04 21:40 -------
Created an attachment (id=8532)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8532&action=view)
Avoid using operator-, version 2.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-04 21:42 -------
*** Bug 20759 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-04 21:45 -------
Neither of the patches are correct.
The correct way is:
complex<T>(lhs) -= rhs;

Note this has to be done for operator - (const complex<T> &lhs, const T &rhs) also.
Should be done for all three "operator -" as 26.2.6 (in the C++ standard) demands that.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-04 21:52 -------
Subject: Re:  operator-(const T&, const complex<T>&) vs
 operator-(const complex<T>&, const complex<T>&)

I don't see how you can trigger wrong behaviour with
operator-(const complex<T> &lhs, const T &rhs):

  template<typename _Tp>
    inline complex<_Tp>
    operator-(const complex<_Tp>& __x, const _Tp& __y)
    {
      complex<_Tp> __r = __x;
      __r.real() -= __y;
      return __r;
    }

Isn't the unary operator- a necessary ingredient for the bug because it
silently changes the sign of zero?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-04 23:18 -------
(In reply to comment #5)
> Isn't the unary operator- a necessary ingredient for the bug because it
> silently changes the sign of zero?

I was just quoting what the standard says.
The exact quote is:
Returns complex<T>(lhs) -= rhs.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-04 23:37 -------
Hi. I suspect some of these issues are well known and general, not specific to
our implementation (e.g., the Std vs signed zeros, see N1612, available from:

  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/)

(p.s., FWIW, I *think* log(a1) is the same for imag(a1) == -0 vs +0)

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-05 14:01 -------
(In reply to comment #7)
> (p.s., FWIW, I *think* log(a1) is the same for imag(a1) == -0 vs +0)

Huhh?  Not if real(a1) is negative.  The branch cut conventionally runs  along
the negative real axis.

For instance, C99 specifies so.  In 7.3.3.2 it also specifies that there it
should be continuous with the second quadrant: "implementations shall map a cut
so the function is continuous as the cut is approached coming around the finite
endpoint fo the cut in a counter clockwise direction."  At least in the absence
of signs on zero.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-05 14:36 -------
Ok, you are right (forgot that your testcases is for negative real part): then
the imaginary part of the log changes from +Pi to -Pi, since it's equal to arg.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-05 14:47 -------
Gaby, what do you think about this issue? In fact, it seems to me that an
implementation strictly following the standard (26.2.6/6), or complex1.patch
here, doesn't not incur in this problem...

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gdr at integrable-solutions
                   |                            |dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pcarlini at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-04-06 08:59 -------
Subject: Re:  operator-(const T&, const complex<T>&) vs operator-(const complex<T>&, const complex<T>&)

"pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| Gaby, what do you think about this issue? In fact, it seems to me that an
| implementation strictly following the standard (26.2.6/6), or complex1.patch
| here, doesn't not incur in this problem...

I think we need more careful analysis and tracking of both C99, C++ and
LIA-3.  Coming to think about it, Bruce I still own you a reply about
the logarithm ; I'll send you all references I have in a separate
mail.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-06 09:17 -------
> I think we need more careful analysis and tracking of both C99, C++ and
> LIA-3.

Ok, thanks, I will start on such analysis (in particulat wrt LIA-3). A minor
issue with complex1.patch is that probably unary operator- is cheaper than
a full subtraction, still, at the end, probably something similar will be
needed. I should also remark that this is definitely not a regression and
that, indeed, the current C++ standard, completely ignores signed zero, NAN,
INF, etc...

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-06 09:27 -------
By the way, about the log, now that you mention it, it's really a pity that we
cannot enable and use the builtin due to the namespace issues with the clog
stream. We should really figure out a way to resolve this annoying issue, humpf!

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-07 20:51 -------
(In reply to comment #11)
> I think we need more careful analysis and tracking of both C99, C++ and
> LIA-3. 

Apart from looking at standards, we could also try to use our brains, right?  It
must be possible to answer the question whether the current behavior is right or
not by analogy with real numbers, ie. simply by looking at the imaginary part alone.

On systems without signed zero, there is no problem.

On systems with -0.0, the code is trying to compute 0.0 - 0.0.  Can that
possibly be -0.0?  If the answer is _no_, then this is a bug and it ought to be
fixed.  Period.  If the asnwer is _yes_, then, well, then I'm bemazed and confused.

BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but
not between 0.0 and +0.0 are slightly broken from a mathematical point of view.
 I would much rather have three zeros: two with signs and one without a sign
that would have to be interpreted as having an indeterminate sign (or even
complex phase).  The "indetermanacy" of the sign could then be reliably
propagated to the result in additions, like this:
 +0.0 + +0.0 == +0.0
 +0.0 +  0.0 ==  0.0
 +0.0 + -0.0 ==  0.0
  0.0 +  0.0 ==  0.0
  0.0 + -0.0 ==  0.0
 -0.0 + -0.0 == -0.0
In such a scheme the sign carries more information than it does on my box which
asymetrically cares about a - sign but not about a + sign.  Sigh.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-07 21:17 -------
> Apart from looking at standards, we could also try to use our brains, right?
> It must be possible to answer the question whether the current behavior is 
> right or not by analogy with real numbers, ie. simply by looking at the 
> imaginary part alone.

Well, Richard, numerical analysis is not a game, is a well defined branch of
applied mathematics, with its theorems and well defined laws: we cannot
reinvent entire parts of it as part of our work. Which here basically is
about implementing standards, to our best, nothing more, nothing less. In
the specific case at issue, Gaby correctly mentions "LIA-3", one of our refs.
I must say, the copy I'm browsing ("Working draft of the First edition,
2002-07-10"), Section 5.2.5, says explicitly that (I'm using here a, more
practical in text mode, simplified, notation):

   x - (z + i * w) -> (x - z) + i * (-w)

We cannot disregard that, I think: before implementing something else we
should at least try to understand why "LIA-3" mandates that.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-07 22:06 -------
(In reply to comment #15)
> Well, Richard, numerical analysis is not a game, ...

Right, but a logical argument is not a game.

>    x - (z + i * w) -> (x - z) + i * (-w)
> 
> We cannot disregard that, I think: before implementing something else we
> should at least try to understand why "LIA-3" mandates that.

Indeed.  Has that standard been released yet?  What's the exact reference, and
is there some public access, maybe to drafts?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-07 22:19 -------
> Indeed.  Has that standard been released yet?

Not to my knowldege.

>                                              What's the exact reference, and
> is there some public access, maybe to drafts?

Yes, I was referring to the draft N481, but actually N490 is more recent (no
changes in the area at issue) both are available from

  http://www.open-std.org/JTC1/SC22/WG11/docs/documents

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-08 08:23 -------
(In reply to comment #17)
> Yes, I was referring to the draft N481, but actually N490 is more recent (no
> changes in the area at issue) both are available from
> 
>   http://www.open-std.org/JTC1/SC22/WG11/docs/documents

Thank you.  It appeards like the current implementation is conforming.

Well, the current behaviour makes perfect sense if we assume that a floating
point value has exact zero imaginary part.  Conceptually, now we have three
zeros: -0.0, the curiously half baked mixture of +0.0 and 0.0 and also an exact
zero.  Crazy.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-04-08 09:51 -------
Yes, I agree that things seem rather crazy, indeed the behavior that you reported
seemed crazy in the first place. I think all of this is a matter of compromises:
when zero is involved the signedness turns out to be very surprising but, in
general, we spare a full subtraction and its risks of cancellations, etc.
Maybe this can explain the behavior mandated by LIA-3.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-04-08 14:15 -------
Subject: Re:  operator-(const T&, const complex<T>&) vs operator-(const complex<T>&, const complex<T>&)

"kreckel at ginac dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #11)
| > I think we need more careful analysis and tracking of both C99, C++ and
| > LIA-3. 
| 
| Apart from looking at standards, we could also try to use our brains, right?  It
| must be possible to answer the question whether the current behavior is right or
| not by analogy with real numbers, ie. simply by looking at the imaginary part alone.
| 
| On systems without signed zero, there is no problem.
| 
| On systems with -0.0, the code is trying to compute 0.0 - 0.0.  Can that
| possibly be -0.0?  If the answer is _no_, then this is a bug and it ought to be
| fixed.  Period.  If the asnwer is _yes_, then, well, then I'm bemazed and confused.

Thatis the mathematical question/answer.  The real issue is this:

  * in operator-(const T&, const complex<T>&), should the imaginary
    part eve be touched?

there are vairous ansewrs.  And, yes we've been using our brains.

| 
| BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but
| not between 0.0 and +0.0 are slightly broken from a mathematical point of view.

If you ask me, any system with signed zeros is broken, to start with.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2005-04-08 14:20 -------
Subject: Re:  operator-(const T&, const complex<T>&) vs operator-(const complex<T>&, const complex<T>&)

"kreckel at ginac dot de" <gcc-bugzilla@gcc.gnu.org> writes:

| (In reply to comment #15)
| > Well, Richard, numerical analysis is not a game, ...
| 
| Right, but a logical argument is not a game.

IT may be a "word ame" though :-)

| >    x - (z + i * w) -> (x - z) + i * (-w)
| > 
| > We cannot disregard that, I think: before implementing something else we
| > should at least try to understand why "LIA-3" mandates that.
| 
| Indeed.  Has that standard been released yet?

It is not released yet.

| What's the exact reference, and
| is there some public access, maybe to drafts?

I think you can have it on WG11 web-site, go to www.open-std.org.

-- Gaby


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- Additional Comments From kreckel at ginac dot de  2005-04-08 22:14 -------
(In reply to comment #20)
> Thatis the mathematical question/answer.  The real issue is this:
> 
>   * in operator-(const T&, const complex<T>&), should the imaginary
>     part eve be touched?
> 
> there are vairous ansewrs.  And, yes we've been using our brains.

I don't understand.  What definition of "touched" is meant here?  Of course,
some sort of "touching" needs to be done because at least for imag(rhs)!=0 we
want to flip the sign bit.

> | BTW: I've always tought that systems that distinguish between 0.0 and -0.0, but
> | not between 0.0 and +0.0 are slightly broken from a mathematical point of view.
> 
> If you ask me, any system with signed zeros is broken, to start with.

Actually, I'm surprised to hear that from you since I was under the impression
that all numerical analysis folks have been smoking Kahan's crack pipe.  :-)

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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[kreckel at ginac dot de]

------- 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; [...])

Interesting.

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
wrongly".

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.  :-(

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[paolo dot carlini at oracle dot com]

------- Comment #24 from paolo dot carlini at oracle dot com  2010-01-06 16:37 -------
As I understand the audit trail, this can be closed. If somebody has solid
reasons to disagree, please re-open.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-30 04:39:57
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20758