
Thank you for your interest and your input. I have corrected the mistakes spotted by Francis Smit and added casts from/to std::complex as suggested by Vicente Botet. Some comments about your proposals. Comparing imaginary and reals seems confusing to me
///Returns true if x equals y template<typename T> inline bool operator==(const Imaginary<T>& x, const T& y); template<typename T> inline bool operator==(const T& x, const Imaginary<T>& y);
The SL offers comparison between std::complex<T> and T which only compare the real part of the complex number and verifies that its imaginary part is zero. I do the same here: I compare the imaginary part of both arguments and verify that the real part of the complex is zero.
The following divide assign operator is missing:
Imaginary<T>& operator/=(const Imaginary<T>& rhs)
I don't think so. If you divide an imaginary number by another imaginary number you obtain a real number which cannot be represented by this class. Hence, the absence of this operator. The same is true for *=.
Many years ago I proposed
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html
Maybe it can be of interest.
This looks like what I'm presenting here. Your proposal goes further in the sense that it also modifies std::complex<T> to add the relevant constructors and operators to the SL complex class but I can't do that here even if it would be more "symmetric" vis-a-vis the real numbers. The complex class could be modified to interact in a better way with pure imaginary numbers but this cannot really be done. I will replace T& imag();
const T& imag() const;
by
T imag() const;
I have modified the code as you suggested as it seems that the norm imposes the latter form for std::complex. Even though I don't really see why. A non-const access could simplify the notation in some cases and I don't see any smarter implementation than just T m_real; T m_imag; but I will conform to the norm and only provide const access. While I like the trick, it could break a lot of code. Could the addition of
a user literal allow to use it as
complex_t z = 4.2 + 3.0i;
I haven't had a look at this until now but this may allow to simplify the notation even more. I see a slight drawback: it uses a C++11 feature which prevents its use with older compilers and these are often the compilers used by scientists on computing platforms. It is quite rare to have access to the last compiler versions in numerical computing. Thanks again for your input. I will "boostify" the code to make it follow more closely the code guiding rules, add a boost-like documentation and prepare more examples. Cheers, Matthieu