[SciPy-Dev] GSOC Optimization Project

[Nathan Woods]

I don’t know a lot about scipy.optimize, but I do have some experience with Fortran/Python interfaces. It seems that f2py essentially treats Fortran code as a black box, and won’t tell you much about what goes on inside. This makes debugging Fortran code being called from Python extremely painful. I imagine that what the PR is describing here is something like this:

Python calls a Fortran library. The library expects to receive a function, which Python provides. This function is coded in Python, and wrapped in an interface that allows to Fortran code to recognize and call it (a Python call-back). 

The Python call-back function contains some error-handling code that raises exceptions under certain conditions. Unfortunately, the Fortran library does not recognize exceptions nor understand what to do with them. The user cannot handle them in the calling code, because the Fortran library is in the middle, and it does not have an interface that can handle exceptions. The upshot of all this is, you have to assume that both the call-back function and the Fortran library are behaving themselves at all times, because the only part of the code the user can really see is the Python calling program. You can sort-of get around this by having the Fortran library and the call-back function return some kind of integer flag to represent certain failure modes, and this is done in a lot of old libraries, but AFAIK there’s no clean, self-documenting way to do it. Hopefully, this is helpful for #1. 

I’m afraid I can’t help much on items 2-4. 

> On Feb 28, 2015, at 11:04 AM, Nikolay Mayorov <n59_ru at hotmail.com> wrote:
> 
> Hi! I want to clarify some things about GSOC project idea related to Levenberg-Marquardt algorithm.
> 
> 1) Why do we want anything but current leastsq based on MINPACK?
> 
> Looks like it is answered here: https://github.com/scipy/scipy/pull/90 <https://github.com/scipy/scipy/pull/90> 
> 
> "When we call python from FORTRAN, a lot of magic has to be done. This magic prevents us, for example, to properly pass exceptions through the FORTRAN
> code."
> 
> Could you comment more on that perhaps?
> 
> 2) What's wrong with https://github.com/scipy/scipy/pull/90 <https://github.com/scipy/scipy/pull/90>? Why it is stalled? What do you expect from GSOC student to do better / different?
> 
> Again partially answered in PR: "It's stalled: the algorithmic part is OK, the new interfaces proposed controversial.", "However, this could perhaps be extended to Levenberg-Marquardt supporting sparse Jacobians"
> 
> 
> 3) Based on 2: how GSOC student should proceed with interface issue? I mean there weren't any strong opinions and it was on the list for so long. I have no idea how to come up with a good solution all of a sudden.
> 
> 
> 4) Do you believe that code written during GSOC should be based on PR mentioned?
> 
> ---
> 
> That's what I come up so far about the work during GSOC:
> 
> - Decide on interface part
> - Add new features to the PR from pv (probably just one of them): 
>    Sparse Jacobians support
>    Constraints support
> - Implement a solid test suite
> 
> 
> ---
> 
> I would appreciate your answers,
> 
> Nikolay.
> 
> 
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20150302/26b66d41/attachment.html>