Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at