[SciPy-User] Least-squares fittings with bounds: why is scipy not up to the task?
Fri Mar 9 02:46:37 CST 2012
Thanks David for this.
The main issue is not in fact to solve the pb for myself (with some variable
substitution or..) as I can also think of e.g. interfacing C/fortran efficient
codes with python via standard wrapping (I had used this with e.g. the amazing
NAG library with the help of expert programmers).
There are 3 issues here (which are closely related to each others):
- to have such a module integrated in scipy means that new python users would
find the module by default and do not need to install more and more modules.
This is one of the problem many people encounter. In the early days of scipy (or
python) things had to be installed, tuned, re-installed, etc. This was fun but
does not allow a large community to join. There are efforts to coordinate,
homogeneise, optimise all this. Scipy is one of these (and an impressive
success). Astropy is another path specific to astronomy (my field). But for such
complex routines, we need (I believe) things which are "simple" to use and
already integrated. I acknowledge this is a huge effort, both to develop the
module, and integrate it and I am not blaming anyone here (on the contrary, as
mentioned, I am very impressed by what has been achieved!). I am just saying: I
believe this is a "must have". People who will need such a module for their own
goals could then use it transparently.
- if the specifics of the bounds/fixed parameters are in the user-defined
function itself, then we loose it I think. To me it is then nearly equivalent
(although slightly better), for a new python user, as having to download and
install several additional packages. You need to spend some time tuning your
function, and cannot change it on the fly. On the long run, I would be surprised
if the "non-advanced" users would really go for this. They would turn to e.g.,
idl or whatever is convenient for them.
- When contributing to an effort like astropy (via e.g., github) and when you do
post a new package, you would like to avoid requiring the installation of 2-3
more packages on top of the one you are proposing (even if their installation is
automatised). At the moment, my package includes mpfit.py as a sub-module. This
is bad practice (as various packages will have various versions of mpfit maybe,
and mpfit is not optimised) but this guarantees that the person who downloads
the package can just rely on that. In astropy, the guideline is that APART from
matplotlib, scipy/numpy, you shouldn't have to download more if you wish to have
a specific piece of software work on your computer. This ensures that the
community reacts positively to this coordinating effort (which is very
significant) and that it will attract more and more people around these
beautiful developments, namely numpy, scipy et al.
Of course, this is just a biased opinion from a non-expert python user! :-)
On 03/09/2012 04:14 AM, David Baddeley wrote:
> From a pure performance perspective, you're probably going to be best setting
> your bounds by variable substitution (particularly if they're only single-ended
> - x**2 is cheap) - you really don't want to have the for loops, dictionary
> lookups and conditionals that lmfit introduces for it's bounds checking inside
> your objective function.
> I think a high level wrapper that permitted bounds, an unadulterated goal
> function, and setting which parameters to fit, but also retained much of the raw
> speed of leastsq could be accomplished with some clever on the fly code
> generation (maybe also using Sympy to automatically derive the Jacobian). Would
> make an interesting project ...
More information about the SciPy-User