Is there any class that can promote a type to the complex type?
Hi, To promote a type, no matter complex or not, to the complex type can be done by the following code. RET would give me a complex type. The code is simple. I'm wonder if boost has already supplied such facility so that I don't have to include the following snippet in my own code. Thanks, Peng #include <complex> #include <iostream> template <typename T> struct convert { typedef std::complex<T> RET; }; template <typename T> struct convert<std::complex<T> > { typedef std::complex<T> RET; }; int main() { std::cout << convert<double>::RET() << std::endl; std::cout << convert<std::complex<double> >::RET() << std::endl; }
AMDG Peng Yu wrote:
I'm wonder if boost has already supplied such facility so that I don't have to include the following snippet in my own code.
<snip> Not to my knowledge. In Christ, Steven Watanabe
Steven Watanabe a écrit :
Not to my knowledge.
I'll take this opportunity to ask the follwoing : would be a properly designed complex class be considered as a potential inclusion to boost (along octonion adn quaternion) ? In everyday life, using std::complex is sometimes cumbersome as some basic operations or conevrtion are lacking.
AMDG Joel Falcou wrote:
I'll take this opportunity to ask the follwoing : would be a properly designed complex class be considered as a potential inclusion to boost (along octonion adn quaternion) ? In everyday life, using std::complex is sometimes cumbersome as some basic operations or conevrtion are lacking
What exactly is missing? Is there any particular reason it can't be added as free functions? In Christ, Steven Watanabe
What exactly is missing? Is there any particular reason it can't be added as free functions?
Well, basically : - a large number of classic mathematic functions. - a real default constructor. Initialising complex<T> to (T(0),T(0)) seems redundant. - automatic conversion between complex of different base types and overload support for complex/scalar interaction e.g : int main() { complex<float> a(1,1); complex<double> b(2,2); complex<float> c; complex<int> d(2,2); complex<float> e(d); // Error : error: no matching function for call // to 'complex<float>::complex(complex<int>&)' c = a+3.f; // works c = a+3; // Error : no match for 'operator+' in 'a + 3' c = a+b; // Error : no match for 'operator+' in 'a + b' } As you said, most of them can be fixed through free function ( the operator overload, the additional math function) and that's what I did for some of my code, but the lack of proper constructors and operator= seems to need some intrusive code fixes. Maybe it's just me that have strange request or write strange code, but it feels strange and counterintutive that the std::complex genericiy is not generic enough : I don't see what's different between adding a float and a double (returning a double) and adding a complex of float and a complex of double (returning a complex<double>). On a side note, some other improvements can be added : - a imaginary<T> class is a possible addition (as long as complex and imaginary interacts together correctly) for some computation. It's only a matter of sparing 4-10 cycles here and there on basic operations. - meta-function that computes types related to complex<T> (as suggested by the original author) like T<->complex<T>, complex types promotions, etc ... Anyway, not sure it warrants a library by itself but I feel those small additions can be interesting. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France
AMDG Joel FALCOU wrote:
What exactly is missing? Is there any particular reason it can't be added as free functions?
Well, basically :
- a large number of classic mathematic functions. - a real default constructor. Initialising complex<T> to (T(0),T(0)) seems redundant.
Isn't that what the std::complex default constructor does?
- automatic conversion between complex of different base types
In complex<float>: explicit complex(const complex<double>&); explicit complex(const complex<long double>&);
and overload support for complex/scalar interaction e.g :
int main() { complex<float> a(1,1); complex<double> b(2,2); complex<float> c; complex<int> d(2,2);
complex<float> e(d); // Error : error: no matching function for call // to 'complex<float>::complex(complex<int>&)'
The standard states that "The effect of instantiating the template complex for any type other than float, double or long double is unspecified." (26.2)
c = a+3.f; // works c = a+3; // Error : no match for 'operator+' in 'a + 3' c = a+b; // Error : no match for 'operator+' in 'a + b' }
As you said, most of them can be fixed through free function ( the operator overload, the additional math function) and that's what I did for some of my code, but the lack of proper constructors and operator= seems to need some intrusive code fixes.
The operators overloads are intrusive, too, since they ought to be found by ADL and its illegal to add functions to namespace std.
Maybe it's just me that have strange request or write strange code, but it feels strange and counterintutive that the std::complex genericiy is not generic enough : I don't see what's different between adding a float and a double (returning a double) and adding a complex of float and a complex of double (returning a complex<double>).
I think that you are correct about operators on two complex types. However, it is probably not a good idea to have operator overloads like the following template<class T, class U> complex<T> operator+(const U& lhs, const complex<T>& rhs); because they can cause ambiguities. In Christ, Steven Watanabe
Isn't that what the std::complex default constructor does? It does and I think it's a bad practice.
explicit complex(const complex<double>&); explicit complex(const complex<long double>&);
Why are they explicit ? Where is the risk to have non-explicit destructor ?
The standard states that "The effect of instantiating the template complex for any type other than float, double or long double is unspecified." (26.2) A point I wasn't aware of. What about enforcing this at the compile-time level using CT-assert ?
I think that you are correct about operators on two complex types. However, it is probably not a good idea to have operator overloads like the following template<class T, class U> complex<T> operator+(const U& lhs, const complex<T>& rhs); because they can cause ambiguities. Is having the followign triplet lead to ambiguity ?
template<class T, class U> complex<T> operator+(const U& lhs, const complex<T>& rhs); template<class T, class U> complex<T> operator+(const complex<T>& lhs, const U& rhs); template<class T, class U> complex<T> operator+(const complex<U>& lhs, const complex<T>& rhs); If it did, shouldn't SFINAE make the cut by restrictng U to types that verify : boost::is_floating_points<U>::value == true ? For me, it looks like complex can be reworked with current technologies to enforce its behavior and adds the missing pieces. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France
AMDG Joel FALCOU wrote:
Isn't that what the std::complex default constructor does?
It does and I think it's a bad practice.
Why?
explicit complex(const complex<double>&); explicit complex(const complex<long double>&);
Why are they explicit ? Where is the risk to have non-explicit destructor ?
they are implicit for float -> double or long double and double to long double. In other words, the constructors are explicit when an implicit conversion would normally generate a warning for the value type.
Is having the followign triplet lead to ambiguity ?
template<class T, class U> complex<T> operator+(const U& lhs, const complex<T>& rhs); template<class T, class U> complex<T> operator+(const complex<T>& lhs, const U& rhs); template<class T, class U> complex<T> operator+(const complex<U>& lhs, const complex<T>& rhs);
Yes. We ran into this with the Units library. If two different class templates define such overloads, then trying to add them is ambiguous.
If it did, shouldn't SFINAE make the cut by restrictng U to types that verify : boost::is_floating_points<U>::value == true ?
Ok. In Christ, Steven Watanabe
Why? I think i'm too deeply rooted into my 'performance' set of mind. I was about to propose an argument about initilizing vector or array of complex to be filled, but I forgot the vector(n,value) methods. SO please disregard this argument.
they are implicit for float -> double or long double and double to long double. In other words, the constructors are explicit when an implicit conversion would normally generate a warning for the value type. OK I see the problem. Is this that problematic that those warning appears ?
Yes. We ran into this with the Units library. If two different class templates define such overloads, then trying to add them is ambiguous. I see but I think disambiguating the overload by any other means is feasable.
Thanks for the discussion. I see now why it's not a clear-cut case. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France
participants (4)
-
Joel Falcou -
Joel FALCOU
-
Peng Yu -
Steven Watanabe