Exposing Bertini 2 to Python - default_precision

9/17/15

In exposing the static method default_precision to Python, I struggled a bit to get the code to compile. I had to look up the spec on the function here at the Boost docs, and saw that it is static in the mpfr_float class. No problem, I just need to learn how to get Boost.Python to resolve the overload.

I tried using the BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS declaration, and its free-function companion BOOST_PYTHON_FUNCTION_OVERLOADS to no avail. The compiler kept complaining about being unable to determine the type of F as an argument in .def or def.

Eventually I caught the trail of this post, but Clang continued to complain about
address of overloaded function 'default_precision' does not match required type 'unsigned int ()'
for the lines
unsigned (bmp::*def_prec1)() = &bmp::default_precision;
void (bmp::*def_prec2)(unsigned) = &bmp::default_precision;

where I was attempting to get a pointer to the correct overload of the default_precision function, and then pass it to boost::python::.def. A little while longer, I found this SO post, and my problem was solved. I simply needed to eliminate the leading namespace bmp = boost::multiprecision::mpfr_float. Voila, now my Python library once again compiles. Thanks to SO, Austin Wagner, and all the other excellent people who so freely share their knowledge on the internet. The correct acquisition of a pointer to resolve overloads is
unsigned (*def_prec1)() = &bmp::default_precision;
void (*def_prec2)(unsigned) = &bmp::default_precision;


Exposing Bertini 2 to Python - conversion to string

9/17/15

This post regards the __str__ function in Python by using str operator in Boost.Python for the mpfr_float class from Boost.Multiprecision.

The docs
here indicated that I ought to be able to implement Python's __str__ method by writing
.def(str(self))
in the
class_<> construct. However, I am getting the error no matching member function for call to 'visit', so something's not lined up correctly.

Problem resolved, regarding compilation.
This conversation thread from 2005 contained the solution for me. Strangely enough, the solution is to use a specific str(), namely self_ns::str(self). This allows compilation to succeed.
Exposing Bertini 2 to Python - operators

9/17/15

I have really been enjoying the experience of exposing Bertini 2's C++ computational core to Python using Boost.Python.

So far, my successes have been in writing wrapper struct / functions for overloads for virtual functions with defaults for a base polymorphic class, exposing a few bits and pieces of my mpfr_complex class, and I am now working on exposing mpfr_float from Boost.Multiprecision in Python.

My current problem is the operators. Most recently, I have been working on the problem of the pow() operator, which in Boost.Python is exposed using .def(pow(self, other)), as written here. However, I was getting errors from Clang to the effect of error: expected '(' for function-style cast or type construction. But in the 1.59 docs, this syntax exactly what I need to use.

That is, for my work on the mpfr_float, I want to write .def(pow(self, other)), to expose taking powers of floats to ints. But the compiler complained. However, I found with a quick internet search this page, which clearly shows the use of () after the name of the other, albeit that the other<> construct is not used. My final line for pow(mpfr_float,int) in Boost.Python is then
.def(pow(self, other() ))
I will figure out shortly whether the
other<> is actually needed here.
Learning about Boost.Python

9/15/15

Predictor and corrector initial adds complete

9/14/15

Today I put an unofficial stamp on the Euler predict and Newton correct code in Bertini2. I have basic tests demonstrating that these methods correctly evaluate a small system, and predict and correct to the correct values. Thanks to Jeb for providing initial test code.

We are getting really close to being able to track a complete path!
Bertini2 Workshop funded

9/2/15

It's official -- the upcoming Bertini2 Workshop is funded by the NSF. Thanks!
Cooperating robots

9/1/15

Two robots in close proximity to each other could assist one another in event of a failure. A free-swinging joint failure, when a motor is unable to deliver torque, is such a situation. A new submission today by myself, Dan Bates, Vakhtang Putkaradze, and Tony Maciejewski, describes a method for optimizing the size of the workspace with respect to the placement of the two robots, and a location for an assistance socket.
Stacks Image 1774