Subject: Re: [boost] Review request: extended complex number library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-03-06 16:24:29
Le 06/03/12 19:49, Vicente J. Botet Escriba a écrit :
> Le 06/03/12 13:28, Neal Becker a écrit :
>> Matthieu Schaller wrote:
>>
>>> Dear all,
>>>
>>> Following the comments from V. Escriba, I formally propose my complex
>>> number library for review.
>>> The library is an extension of the std::complex class addressing two
>>> issues:
>>> - The standard does not guaranty the behaviour of the complex class if
>>> instantiated with types other than float/double/long double.
>>> - Some calculation where pure imaginary numbers (i.e. multiples of
>>> sqrt(-1)) appear are unnecessarily slowed down due to the lack of
>>> support for these numbers.
>>> The code I submit contains two interleaved classes boost::complex and
>>> boost::imaginary which can be instantiated with any type T provided T
>>> overloads the usual arithmetic operators and some basic (real)
>>> mathematical functions depending on which complex function will be
>>> used. It is thus an extended version of Thorsten Ottosen's n1869
>>> proposal
>>> (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html)
>>>
>>> Performance tests show some non-negligible speed-ups compared to
>>> std::complex for calculations where pure imaginary numbers are
>>> involved.
>>> A speed-up of 25% has been observed when solving the Schroedinger
>>> equation explicitly on a regular mesh and some comparable figures
>>> can be
>>> observed when computing the Mandelbrot set (the two examples snippets
>>> provided in the archive).
>>> Furthermore, the functions (sin(), exp(), log(),...) involving
>>> boost::imaginary numbers are more precise than their equivalent using a
>>> std::complex with the real part set to 0.
>>>
>>> The code and (doxygen) documentation is available in the repository
>>> http://code.google.com/p/cpp-imaginary-numbers/
>>> A comprehensive zip archive can be found in the "download" and the code
>>> can also be checked-out via the SVN repository.
>>> The archive contains the class header, two examples, a comprehensive
>>> precision test, a brute-force performance test and the documentation.
>>>
>>> I'd be happy to answer any question from your side and to provide more
>>> detailed information if required.
>>>
>>> Regards,
>>>
>>> Matthieu
>> 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?
>>
>
> Hi,
>
> you are right. The goal been to provide a faster library implies that
> the Boost library should use the standard library when the standard is
> more efficient, and we could expect that the standard is faster for
> the scope it covers.
>
> This means that overloading such as
>
> template<>
> inline float abs(const complex<float>& x)
> {
> return std::sqrt(x.real() * x.real() + x.imag() * x.imag());
> }
> should be replaced by
>
> template<>
> inline float abs(const complex<float>& x) {
> return std::abs(x);
> }
>
>
BTW, the preceding code would work only if the conversion to
std::complex are implicit.
I'm not sure implicit conversion are desirable, but what about explicit
conversions to/from std::complex? and a make_complex function? This
could allow to replace e.g. the code
template<>
inline complex<float> cos(const complex<float>& x)
{
const std::complex<float> temp(x.real(), x.imag());
const std::complex<float> ret = cos(temp);
return complex<float>(ret.real(), ret.imag());
}
by
template<>
inline complex<float> cos(const complex<float>& x)
{
return make_complex(std::cos(std::complex<float>(x));
}
An alternative that could perform better could be to specialize
boost::math::complex for float so that it contains a std::complex<float>
member, let me call it underlying.
template<>
inline complex<float> cos(const complex<float>& x)
{
return make_complex(std::cos(x.get_underlying());
}
Of course, inspecting the generated code will be needed to see if the
compiler is able to optimize this better.
Best,
Vicente