public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/35389] New: error in norm() of STL
@ 2008-02-27 10:45 ywei at qualcomm dot com
2008-02-27 12:44 ` [Bug c++/35389] " rguenth at gcc dot gnu dot org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: ywei at qualcomm dot com @ 2008-02-27 10:45 UTC (permalink / raw)
To: gcc-bugs
There is something wrong with the norm() in STL to get the norm2 of complex
numbers.
Suppose we have complex<double> x(8,1), the norm of x should be 8*8 + 1*1 = 65,
but norm(x) returns 64, which is incorrect.
If we do complex<float> x(8,1), there is no problem, norm(x) does return 65.
The issue is not limited to version 4.2.1. It is observed in other versions as
well.
--
Summary: error in norm() of STL
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ywei at qualcomm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35389] error in norm() of STL
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
@ 2008-02-27 12:44 ` rguenth at gcc dot gnu dot org
2008-02-27 12:44 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-27 12:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from rguenth at gcc dot gnu dot org 2008-02-27 12:43 -------
This works for me. Please provide a testcase that fails.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35389] error in norm() of STL
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
2008-02-27 12:44 ` [Bug c++/35389] " rguenth at gcc dot gnu dot org
@ 2008-02-27 12:44 ` rguenth at gcc dot gnu dot org
2008-02-27 20:13 ` ywei at qualcomm dot com
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-02-27 12:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 12:43 -------
I used:
#include <complex>
#include <algorithm>
#include <iostream>
int main()
{
std::complex<double> x(8, 1);
std::cout << std::norm(x) << std::endl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35389] error in norm() of STL
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
2008-02-27 12:44 ` [Bug c++/35389] " rguenth at gcc dot gnu dot org
2008-02-27 12:44 ` rguenth at gcc dot gnu dot org
@ 2008-02-27 20:13 ` ywei at qualcomm dot com
2008-02-27 20:31 ` pluto at agmk dot net
2008-02-27 20:39 ` pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: ywei at qualcomm dot com @ 2008-02-27 20:13 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from ywei at qualcomm dot com 2008-02-27 20:13 -------
Subject: RE: error in norm() of STL
I did additional test based your test code. You are right that norm()
seems to be fine. The problem happens when I try to cast the return
double value of norm() to unsigned long long (please see my test code
below and the corresponding output). Still, it bothers me that if I
carry out the norm calculation explicitly, instead of calling norm(),
there is no such an issue.
Thanks,
- Yongbin
My test code:
=================================================================
#include <iostream>
#include <complex>
using namespace std;
main() {
complex<double> tt(8,1);
double x, y;
x = norm(tt);
double r = tt.real(), i = tt.imag();
y = r*r + i*i;
cout << tt << "\t" << (unsigned long long)x << "\t" << (unsigned
long long)y << endl;
cout << tt << "\t" << x << "\t" << y << endl;
}
======================================
The output
(8,1) 64 65
(8,1) 65 65
-----Original Message-----
From: rguenth at gcc dot gnu dot org [mailto:gcc-bugzilla@gcc.gnu.org]
Sent: Wednesday, February 27, 2008 4:44 AM
To: Wei, Yongbin
Subject: [Bug c++/35389] error in norm() of STL
------- Comment #2 from rguenth at gcc dot gnu dot org 2008-02-27 12:43
-------
I used:
#include <complex>
#include <algorithm>
#include <iostream>
int main()
{
std::complex<double> x(8, 1);
std::cout << std::norm(x) << std::endl;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35389] error in norm() of STL
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
` (2 preceding siblings ...)
2008-02-27 20:13 ` ywei at qualcomm dot com
@ 2008-02-27 20:31 ` pluto at agmk dot net
2008-02-27 20:39 ` pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pluto at agmk dot net @ 2008-02-27 20:31 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from pluto at agmk dot net 2008-02-27 20:30 -------
Subject: Re: error in norm() of STL
On Wednesday 27 of February 2008 21:13:13 ywei at qualcomm dot com wrote:
> ------- Comment #3 from ywei at qualcomm dot com 2008-02-27 20:13 -------
> Subject: RE: error in norm() of STL
>
> I did additional test based your test code. You are right that norm()
> seems to be fine. The problem happens when I try to cast the return
> double value of norm() to unsigned long long (please see my test code
> below and the corresponding output). Still, it bothers me that if I
> carry out the norm calculation explicitly, instead of calling norm(),
> there is no such an issue.
>
> Thanks,
> - Yongbin
>
> My test code:
> =================================================================
> #include <iostream>
> #include <complex>
>
> using namespace std;
>
> main() {
>
> complex<double> tt(8,1);
> double x, y;
>
> x = norm(tt);
> double r = tt.real(), i = tt.imag();
> y = r*r + i*i;
>
> cout << tt << "\t" << (unsigned long long)x << "\t" << (unsigned
> long long)y << endl;
> cout << tt << "\t" << x << "\t" << y << endl;
> }
> ======================================
> The output
> (8,1) 64 65
> (8,1) 65 65
$ ./a.out
(8,1) 64 65
(8,1) 64.999999999999985789 65
(long long)64.99999 -> 64.
------- Comment #5 from pluto at agmk dot net 2008-02-27 20:30 -------
Created an attachment (id=15239)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15239&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug c++/35389] error in norm() of STL
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
` (3 preceding siblings ...)
2008-02-27 20:31 ` pluto at agmk dot net
@ 2008-02-27 20:39 ` pinskia at gcc dot gnu dot org
4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-02-27 20:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from pinskia at gcc dot gnu dot org 2008-02-27 20:38 -------
This is just the non bug with respect of percussion.
See http://gcc.gnu.org/bugs.html#nonbugs_general
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35389
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-02-27 20:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-27 10:45 [Bug c++/35389] New: error in norm() of STL ywei at qualcomm dot com
2008-02-27 12:44 ` [Bug c++/35389] " rguenth at gcc dot gnu dot org
2008-02-27 12:44 ` rguenth at gcc dot gnu dot org
2008-02-27 20:13 ` ywei at qualcomm dot com
2008-02-27 20:31 ` pluto at agmk dot net
2008-02-27 20:39 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).