 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Felix E. Klee
Guest
|
 Posted: Fri Feb 27, 2004 6:16 pm Post subject: Which complex implementation violates the standard? |
 |
|
Hi,
I found that the complex class implementations included in GCC 3.2.3 and
ICC 8.0 use different methods to initialize the real and imaginary
parts. What I mean is illustrated below:
template<typename type> class ICC_complex_tp {
public:
ICC_complex_tp(const type &re, const type &im) {
z[0] = re, z[1] = im;
}
type real() { return z[0]; }
type imag() { return z[1]; }
private:
type z[2];
};
template<typename type> class GCC_complex_tp {
public:
GCC_complex_tp(const type &re, const type &im) : r(re), i(im) {}
type real() { return r; }
type imag() { return i; }
private:
type r, i;
};
The difference in implementations becomes noticeable when using them in
conjunction with the GMP library (GNU Multiple Precision Arithmetic
Library). The reason is that the precision of a variable of type
mpf_class (that' the GMP floating point class) is set upon
initialization. For example, if "a" is a 128 bit floating point
variable, then
mpf_class b(a);
causes "b" to have 128 bit precision, while
mpf_class b;
b = a;
causes "b" to have the default precision of 64 bit on my system. Thus,
the real and imaginary parts of two complex variables, z1 and z2, that
are initialized with
z1 = ICC_complex_tp(x, y);
z2 = GCC_complex_tp(x, y);
don't have the same precision, if "x" or "y" doesn't have the default
precision.
In a nutshell, what I want to know is this:
Is one of the implementations violating the standard?
BTW, I already looked at the standard and found that the post condition
real() == re && imag() == im
needs to satisfied (in the case of the GMP library, due to the design of
mpf_class::operator==(), both implementations satisfy this condition).
But, isn't this condition somewhat broken? For example, for any
conceivable implementation of complex, there seems to be a type with a
weird operator==() or a weird copy constructor, that violates that
condition.
Felix
PS: To contact me off list don't reply but send mail to "felix.klee" at
the domain "inka.de". Otherwise your email to me might get automatically
deleted!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
 |
Ben Hutchings
Guest
|
| Posted: Sat Feb 28, 2004 12:05 pm Post subject: Re: Which complex implementation violates the standard? |
|
|
Felix E. Klee wrote:
| Quote: | Hi,
I found that the complex class implementations included in GCC 3.2.3 and
ICC 8.0 use different methods to initialize the real and imaginary
parts. What I mean is illustrated below:
snip
In a nutshell, what I want to know is this:
Is one of the implementations violating the standard?
snip |
"The effect of instantiating the template complex for any type other
than float, double or long double is unspecified." (26.2/2)
That'll be a "no", then.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Rob
Guest
|
| Posted: Sun Feb 29, 2004 3:57 am Post subject: Re: Which complex implementation violates the standard? |
|
|
"Felix E. Klee" <felix.klee.news (AT) gmx (DOT) net> wrote
[Example of complex implementations involving a type named mpf_class that
sets it's precision on initialisation snipped].
| Quote: | In a nutshell, what I want to know is this:
Is one of the implementations violating the standard?
|
In a nutshell: no.
.....
| Quote: |
BTW, I already looked at the standard and found that the post condition
real() == re && imag() == im
needs to satisfied (in the case of the GMP library, due to the design of
mpf_class::operator==(), both implementations satisfy this condition).
|
..... as the standard requires these conditions to be satisfied, as they are.
| Quote: | But, isn't this condition somewhat broken? For example, for any
conceivable implementation of complex, there seems to be a type with a
weird operator==() or a weird copy constructor, that violates that
condition.
|
No, it is your expectations of the type that are broken.
Precision supported by mpf_class is not relevant to checking if two
values are equal. You could provide another class to wrap mpf_class
that ensures the behaviour relevant to precision that you expect.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Sun Feb 29, 2004 5:44 pm Post subject: Re: Which complex implementation violates the standard? |
|
|
"Felix E. Klee" <felix.klee.news (AT) gmx (DOT) net> writes:
| Quote: | BTW, I already looked at the standard and found that the post condition
real() == re && imag() == im
needs to satisfied (in the case of the GMP library, due to the design of
mpf_class::operator==(), both implementations satisfy this condition).
But, isn't this condition somewhat broken? For example, for any
conceivable implementation of complex, there seems to be a type with a
weird operator==() or a weird copy constructor, that violates that
condition.
|
If you have a fancy class that has weird operator==() or a weird
copy constructor, then you'll get a weird behaviour.
While from a formal point of view, it is unspecified what you get when
instantiating a std::complex<> with something that is not float,
double nor long double, I would expect that you don't try to feed that
class template with fancy classes with "weird" behaviour.
From a practical point of view, I would expect that if the type you
use to instantiate std::complex<> satisfies the requirement in
26.1 Numeric type requirements
1 The complex and valarray components are parameterized by the type
of information they contain and the manipulate. A C++ program
shall instantiate these components only with a type T that
satisfies the following requirements:
[...]
-- If T is a class, its assignment operator, copy and default
constructors, and destructor shall correspond to each other in
the following sense: Initialization of raw storage using the
default constructor, followed by assignment, is semantically
equivalent to initialization of raw storage using the copy
constructor. Destruction of an object, followed by initialization
of its raw storage using the copy constructor, is semantically
equivalent to assignment to the original object.
From your description, the class mpf_class fails that test.
--
Gabriel Dos Reis
[email]gdr (AT) cs (DOT) tamu.edu[/email]
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
