Re: GSoC application review

[Olaf Till]

Hello Asma,

On Wed, May 06, 2015 at 01:13:19AM +0100, Asma Afzal wrote:
> <snip>
> I have started writing a blog:
> http://octavegsoc15.blogspot.co.uk/
> 
> I have to do a bit more studying to refine my project goals and divide them
> into achievable chunks. I will be discussing with you and Olaf shortly.
> Meanwhile, if you both have any suggestions and pointers then please feel
> free to share.

The blog looks well for me so far, except that I'd like to discuss the
wrapping of 'leasqr' by 'nlinfit'. I think it's better to CC the
maintainers list in this case (done). 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?

I had thought about this feature of 'leasqr' some years ago, and
decided not just to provide it by the new frontent/backend functions
(nonlin_residmin and nonlin_curvefit). The reasons are that:

- providing optimization statistics is not specific to a certain
  algorithm, but only specific to certain optimization criteria
  (weighted least squares, for example),

- 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.

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.

The current situation is that the features of the functions of the new
frontend/backend design are (with one minor exception) a superset of
'leasqr's features.

Since 'nlinfit' has a similar design as 'leasqr', at first glance it
seems to be no advantage to let 'nlinfit' wrap both 'nonlin_curvefit'
and 'curvefit_stat' instead of just 'leasqr'. But if it turns out that
implementing additional features in the wrapped function could help
makeing 'nlinfit' better, then I'd rather like to have these new
features, if they are reasonable, only in the new statistics
functions, without duplicating them in 'leasqr' (maintanance
effort). There are already features in the backends of 'residmin_stat'
and 'curvefit_stat' which are not in 'leasqr'.

Olaf

<snip>

(The other question is dealt with off-list.)

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

signature.asc
Description: Digital signature