Yosef Meller wrote:
I was having my fun with optimize.fsolve() at work, when I realized that both the Python side and the C/FORTRAN side allocate work spaces, and then copy between them, which seemed wasteful. I started playing around with the code to try and create a version that allows the same buffer to move around between Python and minpack.
I couldn't do that (and I doubt now that it's possible), but on the way I found a method to remove the global variables that are used to store the data needed by the multipack functions but not passed in by the FORTRAN code which doesn't even know about it.
The trick was to allocate extra space on the work buffers and use it as a pointer to a structure that contains the information. This may seem just as ugly, but it has all the advantages of not using globals, including the prospects of someday making it thread-safe.
The attached patch implements the trick in minpack_hybrj, and the Python code tests that it works.
Do you think it's worth doing to the rest of the minpack functions?
That is pretty clever. Amy I correct that the only time cost is an extra array allocation (for ap_fvec) per complete calla? I think it is worth it. Using globals requires a bit of rigging to support re-entrance of the optimizers (so you could have a python function that itself calls optimize). Thanks for looking at the code. -Travis