
Boost : 
From: Neal D. Becker (nbecker_at_[hidden])
Date: 20031209 08:24:43
I'd like to suggest that while std::complex has proven very useful, there are
some features missing. Perhaps a boost lib could be helpful.
One are of weakness is in mixed arithmetic. It is fine to use mixed
arithmetic expressions of 'int' and 'double', for example, but not
complex<int> and complex<double>. This lack of symmetry is not logical.
I'm not sure what is the best solution to this problem. I find this function
at least saves a little typing:
template<typename flt1, typename flt2>
inline std::complex<flt1> ComplexCvt (std::complex<flt2> z) {
return std::complex<flt1> (real (z), imag (z));
}
Another area of deficiency is that std::complex<int types> doesn't support the
operators that int supports. For example, operator>>. It is not hard to add
these. This data type is very common in signal processing.
In my area of interest, which includes signal processing, I often write
algorithms that display 2 more attributes. Many times the same algorithm
will support both scalar and complex types. Sometimes a function definition
is standard on complex but is missing on scalar. In particular, I often find
the need for
norm (scalar type)
It is simple enough to add a default definition of norm:
template<typename T> T norm (T x) { return x * x; }
In a number of cases again the same algorithm will work for scalar or complex,
but for an algorithm operating on type T, you need T if T is scalar, but
Scalar<T> if T is complex. Again, it is simple to provide this:
template<typename T>
struct Scalar {
typedef T type;
};
template<typename T>
struct Scalar<std::complex<T> > {
typedef T type;
};
Finally, it is very common that a scalar function can be extended to complex
types by applying the function to the real and imaginary parts independantly.
This function is handy:
template<typename UnaryFunction, typename T>
inline std::complex<T> ComplexFunc (UnaryFunction f, std::complex<T> x) {
return std::complex<T> (f (real (x)), f (imag (x)));
}
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk