Hi Boost, particularly John Maddock and Christopher Kormanyos

first my response to John:
 
From: John Maddock <jz.maddock@googlemail.com>
Date: Wed, 29 Jun 2016 19:28:19 +0100
 
Subject: Re: [Boost-users] Multiprecison: converting a complex class to a number<> backend
 
I suggest you take a look at rational_adaptor which does more or less exactly this but for rational types - if you basically just gut the function implementations from that file, search and replace the class names, and then fill in the blanks you should be 95% there.
 
this is exactly the kind of advice i was looking for, thanks very much!!!  i think i can get started almost right away.
 
This is actually something that's been on our TODO list for far too long, ideally this should be part of the library - fancy helping out - or at least being a testing guinea pig?
 
absolutely, i would love to help with this.  the major challenge I see for getting everything fully functional in my active codebase using the new backend is Eigen.  I continue to push the boundaries of Eigen with respect to expression templated numeric types, ha.  i absolutely love that library!  by the time I am done with my code, it will be expressions and templates the whole way down.  i am guessing that personal emails or the dev list are the best place to continue discussion of helping work on this part of the library?
 
I quickly mocked up an example (attached) of how I think this should look if we were to add it to the library, basically:

thanks for the mock-up!  
 
As noted in the attached example, we really need another number category for complex types, and while mixed arithmetic with (real) scalars will just work, if you wanted an imaginary type as well, that would involve a whole lot more work, as class number does not currently support return a type different from either argument type in the binary operators (for real + imaginary for example).

mixed real-complex is enough for me for now, adding imag-real specializations won't affect much of my codebase, so not currently a high priority for me.  sometime over the rainbow, it might become important, but not right now.
 
And finally... there is this: https://code.google.com/archive/p/cpp-imaginary-numbers/ which takes a different view of things (but loses multiprecision's expression templates).

I really need the expression templates, but this is a good resource.  thanks for the link.
 
PS, one final note: ideally this would be handled by std::complex, but sadly that class can not be instantiated on any type other than float/double/long double with invoking undefined behaviour.

agreed.  the STL's most disappointing template to me: the std::complex.  i was disheartened to feed in higher precision types, and get only double precision out of atan.  then i found out about the invocation of UB resulting from what i had done...  
 
thanks for the response, John.  you are always most helpful, and I really appreciate your time.

----------

second, my response to Christopher and John

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.

should be a relatively easy conversion, to add template parameters to my class, and replace the hard-code of real_ and imag_ type.  this is definitely a desirable modification, though not a pressing need in my context.  It would be nice to be able to use any type.  John, I think we should talk about the final needs of a complex_backend for inclusion in the multiprecision library.

Thanks for the response Christopher.

Thanks for reading and responding!  
Daniel