Le dimanche 25 décembre 2011, Vicente Botet <vicente.botet@wanadoo.fr> a écrit :
Matthieu Schaller wrote
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.open-std.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 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 boost::complex<> class.
Is there anything that prevents the use of the standard std:.complex in
the
specializations of boost::complex<> boost::imaginary<> for float and double?
Nothing but the idea of having a stand-alone package. Regards, Matthieu