On 29/06/2016 22:17, Christopher Kormanyos wrote:

In my opinion, trying to adapt a complex number class to the backend requirements of number might not be the best way to go.

I would recommend writing an extended complex template class that is intended to be instantiated for both user-defined types as well as float, double and long double.

The real and imag parts are template parameter types. They could be of type mpfr_float because the template parameter type is determined at compile-time when the class is instantiated.

In the winter, I wrote an extended complex class and tested it extensively with multiprecision and fixed point. There was also another candidate implementation of extended complex a few years ago from another developer, but it never got to review.

I have not yet made my extended complex code available.

I am not subscribed to the user's list. If the post gets to the developer's list, there is a good chance I will see it.

I'm curious as to what you see as the stumbling block to providing a complex number backend to class number<> ? The main advantages are that the expression-template code and all operator overloads are "just there" already, what do you see as the drawbacks? Best, John.