octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSoC application review


From: Olaf Till
Subject: Re: GSoC application review
Date: Sat, 9 May 2015 22:35:07 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, May 09, 2015 at 08:20:40PM +0100, Asma Afzal wrote:
> Hi Olaf,
> 
> >Looking at the documentation of  'nlinfit', I'd guess the returning of 
> >additional statistics is the
> > reason you chose 'leasqr' to wrap. Is that so?
> 
> Yes, precisely. But, I wasn't aware of 'residmin_stat' and
> 'curvefit_stat' before.
> 
> > - one should not be forced to repeat a possibly lengthy optimization
> >   to get additional statistics, but be able to just use the result of
> >   the optimization for this purpose.
> 
> >From what I understand, 'leasqr' needs to be provided with a function
> to compute the Jacobian of the residuals.
> The default function 'dfdp' computes numerical partial derivatives
> with finite differences method.
> In [1] you mentioned that the finite differences are handled in a more
> sophisticated way in
> 'nonlin_curvefit/residmin' as a default argument helps identify the
> parameter the partial derivative is associated to.
> Trying to read through the code, I am assuming that argument is
> 'hook.plabels'? (Please correct me if I'm wrong).

I don't see a connection of the above part of your post to what you
cite from my post above ... My point was not that the optimization
should be faster, but that the optimization should not need to be
repeated at all. (With leasqr it is repeated each time you request
computation of some statistics.)

But to answer your question: A part of the necessary information is in
a field 'plabels', yes, and the finite differencing function gets it
in argument 'hook'. The model function gets only a slice of it,
corresponding to the parameter of the current partial derivative, so
it can determin the parameter which belongs to the current partial
derivative; the fieldname is 'plabels' again, but the argument name of
course depends on the model function.

This is not the only informational argument which may be used for such
time saving. If you want to inform yourself about this, then instead
of first trying to read the code, you could first read optim_doc(),
where all this should be specified for function nonlin_residmin.

But since the project is to write wrappers which are Matlab
compatible, we should just delete this informational argument for the
model function. (This can be easily done by calling the model function
with an anonymous function.)

> > This led me to make separate functions for optimization statistics
> > (residmin_stat, curvefit_stat). They are frontends, similar to
> > nonlin_residmin and nonlin_curvefit, although currently they have only
> > backends for weighted least squares.
> 
> Nlinfit uses iterative reweighted least squares with different
> weighting functions for estimation. A similar function is 'robustfit'
> [2]

I've not yet informed myself what that means. But if it's different
from what we have in residmin_stat, than leasqr doesn't help; as I
said, residmin_stat has (with a minor exception) a superset of leasqrs
statistics functionality.

> I started with a small example to see how lsqnonlin, lsqcurvefit and
> nlinfit are related:
> 
> http://octavegsoc15.blogspot.co.uk/
> 
> I think the next step should be to jot down the mapping of all these
> functions to Octave's nonlin_residmin, nonlin_curvefit, residmin_stat
> and curvefit_stat.

Yes, probably.

> [1] 
> http://octave.1599824.n4.nabble.com/Financial-Grid-search-leasqr-to-fit-3-parameters-How-to-speed-up-tp3675973p3709403.html
> [2] http://uk.mathworks.com/help/stats/robustfit.html

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]