Re: [Boost-users] Multiprecison: converting a complex class to a number<> backend (John Maddock)

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