Using state of the art C and Fortran libraries in quantecon

[davidrpugh]

This is a placeholder issue for discussing the possibility of including code using various scientific computing libraries developing by U.S. national labs. Examples include...

• PETSc
• Trilinos
• TAO
• COOPR
• PATH

...amongst others. Python bindings for the first four of these projects already exist:

• petsc4py
• tao4py
• PyTrilinos
• Pyomo

Most of these packages provide state of the art routines for solving large systems of linear, and non-linear equations, non-linear optimization, etc. These routines are significantly better than those available via SciPy. In case you are wondering, I was exposed to most of these technologies as ZICE this past February.

Another interesting alternative is to make use of the NEOS. NEOS has a Python API which one can use to push an optimization/root finding problem to the server and retrieve the results for post processing.

I am not suggesting that we should make any of these tools dependencies of QuantEcon: there are too many architecture specific build requirements (I am not even sure that all of the above tools can be built on a Windows PC). We should consider, however, showing how they can be leveraged from within Python.

[jstac]

Many thanks for these thoughts. This is an important topic. Since we don't want to make these libraries dependencies --- I agree on that point --- one option is to feature them in an IPython notebook. As we develop the quantecon website we can look to include a collection of notebooks there. It would be nice to have a notebook that showed how to use those more advanced solvers.

[albop]

I completely agree with the comment above.
One nice thing to have (if one is willing to leave with a strange license) would be a wrapper to the PATH solver that can be very useful for complementarity problems when they can't be solved using more straightforward techniques. (this is the approach of http://www.recs-solver.org/)

[jstac]

At this stage our approach is that our dependencies should be essentially isomorphic to what's currently in Anaconda.