Multiprecison: converting a complex class to a number<> backend
Hi Boost, I have implemented my own complex class wrapping around Boost.Multiprecision number<>, particularly mpfr_float. Now, I'd like to take the class I've written, and extend/convert it into a backend suitable for use in number<>. While I've read the documentation describing the requirements for a backend http://www.boost.org/doc/libs/1_61_0/libs/multiprecision/doc/html/boost_mult..., and think I understand what I need to do, I have found 0 examples in the wild. My current setup has a pair of files mpfr_complex.hpp, mpfr_complex.cpp describing something like (just what you'd expect, really) --------- class complex{ mpfr_float real_, imag_; public: // the *= family of operators, getters, setters, // some factory functions, etc }; //the free operators defined down here, along with pow, exp, etc. -------------- I think what I'd like to write is a new complex_backend.hpp file which implements the required functions for the complex wrapper around mpfr_float. In this file, I believe I implement the family of functions such as eval_multiply(b, a) in terms of the operators for my complex class. Is this right? In a related vein, with et_on for mpfr_float, I've started adding templated overloads for the complex operators and math function accepting expressions of reals, and I think this is going to get out of hand, so using number<> would conceivably save me a ton of time writing my own functions. It will also save me a ton of errors for hand-writing the expression templates for complexes, which appear to be ready to go from Boost.Multiprecision once I get a backend implemented. Again, my goal is expression templates for complexes with real and imaginary fields consisting of mpfr_floats, leveraging the number<> template, with et_on, and my own backend. Do you have any advice? Any references to any other custom backends? Daniel Brake University of Notre Dame Applied and Computational Mathematics and Statistics
On 28/06/2016 20:49, Daniel Brake wrote:
Hi Boost,
I have implemented my own complex class wrapping around Boost.Multiprecision number<>, particularly mpfr_float. Now, I'd like to take the class I've written, and extend/convert it into a backend suitable for use in number<>. While I've read the documentation describing the requirements for a backend http://www.boost.org/doc/libs/1_61_0/libs/multiprecision/doc/html/boost_mult..., and think I understand what I need to do, I have found 0 examples in the wild.
My current setup has a pair of files mpfr_complex.hpp, mpfr_complex.cpp describing something like (just what you'd expect, really)
--------- class complex{ mpfr_float real_, imag_;
public: // the *= family of operators, getters, setters, // some factory functions, etc };
//the free operators defined down here, along with pow, exp, etc. --------------
I think what I'd like to write is a new complex_backend.hpp file which implements the required functions for the complex wrapper around mpfr_float. In this file, I believe I implement the family of functions such as eval_multiply(b, a) in terms of the operators for my complex class. Is this right?
Yes.
In a related vein, with et_on for mpfr_float, I've started adding templated overloads for the complex operators and math function accepting expressions of reals, and I think this is going to get out of hand, so using number<> would conceivably save me a ton of time writing my own functions. It will also save me a ton of errors for hand-writing the expression templates for complexes, which appear to be ready to go from Boost.Multiprecision once I get a backend implemented.
Again, my goal is expression templates for complexes with real and imaginary fields consisting of mpfr_floats, leveraging the number<> template, with et_on, and my own backend. Do you have any advice? Any references to any other custom backends?
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 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?
I quickly mocked up an example (attached) of how I think this should
look if we were to add it to the library, basically:
template<class Backend>
struct complex_adaptor{ /* details */ };
Then complex number typedefs that mirror each floating point typedef:
typedef number
participants (2)
-
Daniel Brake
-
John Maddock