Re: [boost] Determining interest: Pure imaginary number library

Subject: Re: [boost] Determining interest: Pure imaginary number library
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-11-29 07:39:17

>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, ...

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'm hoping eventually to extend the "mp_number" stuff in the sandbox (under 
the "big_number" directory) to cover complex extended precision arithmetic, 
but it may take a while :-(

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).

Apologies for not jumping in on this discussion before... John.