Re: GSoC application review

[Juan Pablo Carbajal]

On Sat, May 9, 2015 at 10:35 PM, Olaf Till <address@hidden> wrote:
> 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

Sorry to be the guy doing this, but if the topic of your conversation
has drifted away from "Reviewing GSoC applications" please start a new
thread with the corresponding title.

Sorry, and thanks for your understanding.