Dear all, Thanks for your comments. How about having a boost::real<T> (or whatever you want to name it), that references a complex number with an imaginary part set to 0? This could in principle be done but I don't think that it is a good thing to do. boost::real<> would be a wrapper around the double type say. Now, this would require to rewrite all the mathematical functions for this type. Furthermore, people doing numerical sciences will probably not be keen to drop the use of native POD variable for simple calculations. It is true that some functions could be modified to return complex values instead of NaNs but this would come at a performance cost when performing real only computations. Seems quite interesting. One issue I have though, as a user of gcc/libstdc++, I see that the versions of many std::complex operations seem to be optimized in terms of gcc builtins. For example: #if _GLIBCXX_USE_C99_COMPLEX inline float __complex_abs(__complex__ float __z) { return __builtin_cabsf(__z); } inline double __complex_abs(__complex__ double __z) { return __builtin_cabs(__z); } So if I switched to boost::complex, I'd loose these optimizations. Is it useful to have an imaginary library that complements std::complex, rather than replaces it? I am actually using the std::complex<> versions for all non-trivial operations. This means that built-in functions can be used by the compiler. Now, you found one example (abs()) where this is not done. Measurements showed that this was not necessary for this particular operation but for consistency, I could do this for all operations. I'm not sure implicit conversion are desirable, but what about explicit conversions to/from std::complex? and a make_complex function? I don't think that implicit conversions to/from std::complex should be used. But you are right, I should provide an explicit conversion constructor and a make_complex function. I could then write template<> inline boost::complex<float> cos(const boost::complex<float>& x) { return boost::complex<float>(std::cos(make_std_complex<float>(x)); } Cheers, Matthieu -- Matthieu Schaller