Open pathfinder49 opened 5 years ago
We might just want to give the option of passing **kwargs
to FitBase.fit
.
If set to ‘jac’, the scale is iteratively updated using the inverse norms of the columns of the Jacobian matrix (as described in [JJMore]).
That's more or less what I was referring to – would this work for us? If we can avoid having to manually set this in 99.999% of cases, this seems like a huge win.
That might do the trick. Would it hurt to expose **kwargs though?
Probably not – at least if it's a named dictionary (curve_fit_args
? fit_args
? algorithm_options
?), where it doesn't make the FitBase
API more convoluted. I'd just like to avoid making the common case more complex.
I've modified FitBase
to use x_scale='jac'
. However, **kwargs
should still be exposed.
Will do that later.
We might need update scipy
in our artiq-env
for that to work, by the way.
Un-assigning myself, as FitBase
seems like a lost cause (or, to be more precise, requires serious amounts of work to be generally useful for my experiments, like proper support for multi-dimensional data), and I'm thus unlikely to do much work on it.
Fitting with parameter values far from unity can be improved by passing characteristic parameter scales to
curve_fit
using the optional thex_scale
keyword argument. This argument is documneted underscipy.optimize.least_squares
.curve_fit
calls this function internally.**kwargs
tocurve_fit
are passed toscipy.optimize.least_squares
.