Boost Users :
Subject: Re: [Boost-users] Multiprecison: converting a complex class to a number<> backend (John Maddock)
From: Daniel Brake (danielthebrake_at_[hidden])
Date: 2016-06-30 12:52:18
Hi Boost, particularly John Maddock and Christopher Kormanyos
*first my response to John:*
> From: John Maddock <jz.maddock_at_[hidden]>
> 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
> 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
Thanks for the response Christopher.
Thanks for reading and responding!
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net