Support for python3


#1

I wonder if there has been any progress on this. I saw this post from two years ago: Python3 support . Are there plants to update it in the near future? I don’t know if it could be as simple as running an automated tool to port it to python3 or if there is some other implementation in mind (like the cython mentioned in that post)


#2

Hi, Miguel! The short answer is, yes, we intend to support Python 3 in the near future especially with the end of life coming to Python 2 in 2020.

The long answer is that we’ve been slow playing this for the following reasons:

  1. At the moment, adding a new variable to the optimization state requires code changes in 15 places. Four of those places pertain to MATLAB/Octave and three of them pertain to Python 2. Adding support to Python 3 just extends that. Now, the problem isn’t Python 3 per se, but that the current infrastructure for supporting new languages is not sufficient for long term maintenance.

  2. Theoretically, Cython can reduce this cost, but not really. At the end of the day, we need to support other languages as well, so any solution to the above issue needs to be somewhat language agnostic.

  3. The other issue with Cython is the amount of code necessary to properly denote which language owns what. At the moment, Python owns the vectors and the optimization functions, but C++ owns the the state. On the surface, this is fine, but it becomes somewhat complicated given that the C++ side of Optizelle calls back into the Python side, which sometimes requires a translation between a C++ state and Python state. All of this can be managed through the C-API, but I’ve never been convinced that Cython would make this easier.

  4. Ultimately, there are a few design changes that will make this easier

    1. A code generation facility that will create the wrapper code for each language that interfaces to Optizelle as well as the manual. Basically, this means that there is a single place where new variables are added and the changes are automatically filtered to everywhere they need to be.

    2. A different abstraction and design of the optimization state to make it easier to pass it between the different supported languages.

Now, we actually have code for all of this, but this is part of an overall redesign that also improves the algorithms and how we interact with them. For example, there’s a methodology to abstract a vector space, to checkpoint solutions, to define and execute preconditioners, etc. At the moment, it’s made more sense to just roll out all of these changes at one time rather than to try and integrate them in a piecemeal manner. Simply, there’s a lot of code to change and the new algorithms and interfaces forced a fundamental redesign of the code.

Alright, so where are we at specifically? We have a prototype code that we are not currently distributing, but are testing to make sure that we’re happy with the algorithms. By mid year, it’s my hope that the algorithms and interfaces are settled and fixed. They’re really not changing that much right now, but I really want something reliable before we push out more code. At that point, we’ll start on the production code, which will likely take some months to complete. I’d like it to be done by the end of the year.

In any case, feel free to check-in and I’ll do my best to keep you in the loop on how things are progressing. I’ve been terrible about updating our website with updates, but rest assured that there’s been steady development. We hope to have all of that released in the not too distant future.

Joe