Python bindings

[Taylor Braun-Jones]

Just wondering if there are any plans for python bindings. Or, even better, is there a roadmap ceres-solver feature development in general? That would be nice to have even if it is subject to change.

Ideally, the python interface would still support auto-diff one way or another. From a quick web search I found this project that is currently filling the gap:

https://github.com/rll/cyres

Maybe a good starting point for integrating into the main ceres-solver code base?

Taylor

[Sameer Agarwal]

Hi Taylor,

There is no official roadmap. We develop features for ceres as the need arises for them.  I think bounds constraints in the gradient based solver and better support for constraints in the trust region solver.

Python bindings have been a topic of discussion a couple of times. In fact the whole reason a C API (include/ceres/c_api.h) exists is to allow integration with scripting languages like Python and Lua. But unfortunately this has not happened.  I think part of the problem is automatic differentiating requires c++ templates.

The cython interface that you link to is most sophisticated set of python bindings that I know of and I'd be quite open to integrating it into main solver code base. Would you be willing to lead the charge here? We'd be more than happy to review the CLs.

Sameer

--
You received this message because you are subscribed to the Google Groups "Ceres Solver" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ceres-solver...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAKfKJYsAidnhLeQx_qicD_CfvMeqZcTD74ryLhLuL%2BE2b9T3PA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Keir Mierle]

Hi Taylor,

We've had plans for Python bindings for some time but they haven't materialized. We've had a couple of requests but not major engagement. Another issue is autodiff: there isn't a reasonable way to reuse the autodiff code in Ceres in Python. It makes more sense to use a separate autodiff mechanism.

With all that said, we would love to have Python bindings as part of Ceres core. Can you explain your use case so we can better understand what you would like to use Ceres for in Python?

Thanks,

Keir

--

[Taylor Braun-Jones]

Thanks for the replies. My use case is for some simple PyQt4 applications that collect various pieces of data and feed them into an optimization problem. With Python bindings for ceres-solver this could be all done in pure Python without the headache of having to deal with a C interface to my own C++-based ceres-solver problem.

In thinking about a possible solution to the problem of including autodiff in the ceres-solver Python interface I came across a couple C/C++ inlining options that would allow a Python programmer to write just the templated cost function in C++ and the rest in Python:

scipy.weave: http://docs.scipy.org/doc/scipy/reference/tutorial/weave.html

PyInline: http://pyinline.sourceforge.net/

But then I realized that I can just use these to embedded my entire (C++) ceres-solver problem definition and achieve basically what I'm going for. If that works out well, maybe I'll see about submitting a minimal example that demonstrates this approach to using ceres-solver inside a Python code base.

Taylor

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CADpYijHJnE1NAHCByrxJerVxQ4CTx6YC%3D7jz152PQ2hZxoA%2Btg%40mail.gmail.com.

[Sameer Agarwal]

Taylor,
I'd love to know if you get it working with either weave or pyinline. A section in the documentation and some example code would be perfect.
Sameer

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAKfKJYuQUmJw%3D3gPZtT-T%3DGvCH7cdgpFkU8HqdVNFpYpy2z8UQ%40mail.gmail.com.

[Dustin Lang]

FWIW, another option that I have used is to write a python extension module (eg, using swig) in C++, with a function that calls the ceres code.  You also need to write a C++ wrapper that calls back to your python functions!  This doesn't allow autodiff though.  My implementation is not at all general, but just thought it might be helpful to say that this approach can work.  I wrote a CostFunction subclass whose Evaluate method wraps the parameters that ceres sends as a numpy array, then uses PyObject_CallMethodObjArgs to call back to a python method to produce the Jacobian.

cheers,

--dustin

To view this discussion on the web visit https://groups.google.com/d/msgid/ceres-solver/CAK0oyEqtxLOf%3DTrcmjUx6nFc62Q9WUnwvR%3DmwQCafPs4eZonvg%40mail.gmail.com.

[Martin Karlgren]

Hi,

On Wednesday, January 28, 2015 at 5:57:44 AM UTC+1, Keir Mierle wrote:

We've had plans for Python bindings for some time but they haven't materialized. We've had a couple of requests but not major engagement. Another issue is autodiff: there isn't a reasonable way to reuse the autodiff code in Ceres in Python. It makes more sense to use a separate autodiff mechanism.

 A possible solution for the autodiff issue might be to represent the parameter blocks as objects and return operand objects, which are symbolic representations of the corresponding parameter, when a parameter block is indexed. The operand class would overload the relevant operators, and the base class of the ”cost function” (implemented in Python) would implement its own variants of the mathematical functions (abs, pow, sin, etc.) The overloaded operators and functions may then successively build an expression tree that’s passed through each operand back to the residual block object. The expression tree for each residual can then be evaluated dynamically by the cost functor for each iteration, thereby enabling native autodiff.

This means, in theory, that the Python callback only needs to be called once, as long as no parameter comparisons are performed (e.g. ”residual[0] = (param[0][0] < 0) ? param[0][0]*2 : param[0][0];” or similar.) However, the comparison operators (>, <, ==, etc.) could be be overloaded for parameter operands, so that the Python callback can be reevaluated if a comparison result doesn’t match that from the previous call. (Or, just reevaluate the Python callback for each iteration if parameter comparisons are detected.)

I’ve implemented a proof-of-concept glue for the Pike programming language (http://pike.lysator.liu.se/), since that’s the language my application is implemented in. It only supports a single cost function/residual block per problem at this point, and the comparison issues aren’t resolved yet, but it works for simple problems. (Also, for performance, the expression tree should perhaps be replaced/converted to a postfix representation that can be evaluated by a simple stack machine.)

Here’s the PoC glue: https://github.com/marty-se/pike-ceres

Sample usage: https://github.com/marty-se/pike-ceres/blob/master/test.pike

I’ve looked into Cyres and it seems the same approach would be feasible there, but since this is a when-the-kids-are-asleep-project I haven’t really had the time to implement anything (yet.)

Just my thoughts... and by the way, thanks for a great solver.

Martin

[Arjun Singh]

Hi,

I wrote the cython interface about a year and a half ago. The motivation for me was just to be able to build the optimization problems in Python to reduce the amount of bookkeeping needed in C++ -- I wasn't as interested in actually writing the cost functions in Python (though that'd be pretty cool).

I'd love to see it get integrated. Unfortunately, I haven't been working on projects that use ceres as much recently, so I don't know if I've got the time. I'm also not sure how much effort it would take to integrate. Do you have ideas on what would be involved, and how you'd like to proceed? I'm also happy to hand it off to someone else that's still frequently working with ceres.

Thanks,
 - Arjun

[Jesús Briales García]

Has there been any updates on the status of Python bindings for Ceres since this discussion?
I know there are now frameworks such as pybind11 which streamline a lot wrapping C++ functionalities from Python,

so just wondering if we have any relevant option to use/look at at this point.