
Boost : 
Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 20111224 10:08:46
Le 29. 11. 11 17:31, Matthieu Schaller a écrit :
> Le 29. 11. 11 12:39, John Maddock a écrit :
>>> I also think that it will be worth defining a boost::complex class
>>> on the style of the rejected standard proposal that will integrate
>>> better with the imaginary class.
>>> The standard complex class has a constraint that a boost::complex
>>> class could avoid, it only accepts the builtin double and float
>>> types. This complex class could accept any type conforming to the
>>> expected Concept. I'm sure that others are expecting a complex class
>>> that can be used with specific classes, as arbitrary precision, ...
> This can be done. The boost::complex class could simply be an
> implementation of the n1869 draft by Thorsten Ottosen then:
>
> http://www.openstd.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html
>
> With the addition of the TR1 reciprocal trigonometric functions and
> the small updates brought by C++11.
> On top of this, some mathematical operators could be specialized for
> float and double if some performance improvements can be obtained in
> those cases.
> I will work on this.
Dear all,
Some news about this idea. I worked on an implementation of a complex
number library which should work with any time T providing the relevant
operators and basic mathematical functions.
The design I had in mind is the following: provide a template class and
specialisations for the float, double and long double types using the
basic mathematical SL functions for these three types wherever required.
This is fine and works in a satisfactory way in terms of precision. Now,
this way of doing the computation is much slower than the SL version of
std::complex<>. This is simply because the standard functions use
builtin functions which in some cases can be as much as ten times
faster than purely applying the mathematical definition. In other words
a boost::complex<> library would be outperformed by the std::complex<>
library in almost all nontrivial computations when used with the POD
floating point numbers.
Does someone have an idea of how these issue could be solved ? As such a
performance drop almost kills all the motivation to use such a
boost::complex<> class.
Regards,
Matthieu Schaller
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk