Subject: Re: [boost] Determining interest: Pure imaginary number library
From: Matthieu Schaller (matthieu.schaller_at_[hidden])
Date: 2011-11-29 11:31:54
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
I will work on this.
> Before we all get too carried away, there is an issue with
> "mycomplex<my_big_num>" which is that if "my_big_num" implements
> expression templates to optimize arithmetic operations, then these
> expression template end up in the wrong place with
> "mycomplex<my_big_num>" : which is to say inside mycomplex's
> implementation, instead of on mycomplex's own external operators
> (which is where you really need the expression templates given that
> each mycomplex temporary will contain 2 values).
I may be wrong but I don't see how complex numbers could benefit from
template expressions. The two "components" get mixed in almost every
expression and cannot be decoupled. The complex<> class always ends up
using the operators of its template argument which in the case of a
GMP-like number means that the appropriate template operators are called.
The complex number operators always end up using real number arithmetic.
So mycomplex<my_big_num> would use your "improved" operators.
> And finally, there's already a small amount of complex number code in
> Boost under Boost.Math (just adds some extra TR1 functions), so if
> adding imaginary support is small enough, we could adopt it under
> Boost.Math I guess - or vice versa if the new code is large enough to
> warrant having it's own library. Just thinking out loud here that it
> would be better to have all the complex number code in one place if
> possible (and it makes sense to do so).
The TR1 operators could be moved into (next to) this new complex<> class
in order to group everything. I would anyway have to implement them if I
want the class to be as close as possible to the SL-one as these
mathematical functions are now part of the standards.
Thanks for your input.
-- Matthieu Schaller
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk