Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 2011-12-24 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:
> 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.
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
built-in 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 non-trivial 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