[SciPy-User] adding linear fitting routine

[Evgeni Burovski]

IMO it would be good to have some degree of uniformity between `minimize`,
`curve_fit` and this new routine. Both in terms of return types
(`optimize.Result`?) and in terms of keyword arguments (`full_output` etc).


On Thu, Dec 5, 2013 at 10:43 AM, Skipper Seabold <jsseabold at gmail.com>wrote:

> On Thu, Dec 5, 2013 at 12:26 AM,  <josef.pktd at gmail.com> wrote:
> > On Wed, Dec 4, 2013 at 6:58 PM, Daniele Nicolodi <daniele at grinta.net>
> wrote:
> >> On 05/12/2013 00:21, David J Pine wrote:
> >>> Of course, that's the point of designing for backwards
> >>> compatibility--you don't see the need for more information when you
> >>> write the code, otherwise you would include it.  But as code gets used,
> >>> you sometimes see things you didn't see before.  So it's good to write
> >>> code that allows for unforeseen changes.
> >>
> >> If this is the reasoning, all functions or methods should return
> >> dictionaries.
> >
> > some functions are reasonable targeted that we don't expect many changes.
> > I wouldn't know what else numpy.sum could return.
> > (numpy.nanmean also does the count of the non-nans but doesn't return
> it.)
> > we copied numpy.linalg.pinv into statsmodels because it doesn't give
> > as the singular values.
> > scipy.linalg got the change to optionally return the rank, with new
> > keyword `return_rank`
> >
> > Sometimes the reply on issues in scipy is that we cannot add to the
> > return or change it because it's not backwards compatible. I would be
> > happy if I could change the returns of stats.linregress.
> >
> > In the case of linfit or curve_fit, there are many possible additional
> > returns that we might want to add if the demand is large enough.
> > Last time there was a question, I argued against curve_fit returning
> > the std_err, i.e. np.sqrt(np.diag(pcov)) to keep it as just a minimal
> > fitting function.
> >
> > I'm not a big fan of dictionaries because I don't like to type ["   "]
> > instead of just a dot.
> >
>
> Maybe this is an opportunity to start introducing the Bunch pattern
> into scipy. From what I remember, the tuple returns were encouraged
> because scipy is a "library," though, of course, this leads to all the
> problems already pointed out. And it seems silly to just stick to this
> policy for its own sake.
>
> I've been using R quite a bit recently for some work, and they often
> return R lists, which are essentially what we get from a Bunch. It's
> quite nice, and I'm now finding tuples of returns to be pretty rough.
>
> Skipper
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20131205/43e24fe1/attachment.html>