Re: lsqnonlin and nonlin_residmin

[Olaf Till]

On Sun, Jun 07, 2015 at 05:17:33PM -0700, AsmaA wrote:
> Hello,
> 
> Thank you for your review.
> 
> >before a thorough review, could you first implement the issue with the
> >user-supplied Jacobian? Or tell me if you need advise with that.
> 
> I have implemented the user-specified jacobian functionality (not very sure
> about it since there is not much documentation of dfdp).

'not much documentation' -- that surprises me ...

> Can you please
> check?

Looks ok to me so far, but 2 details should be changed:

1. In function 'computeJacob', use '[~, Jacob] = modelfun (p0);'
   instead of '[fun, Jacob] = modelfun (p0);'. So 'modelfun' might be
   able to spare some computations.

2. You can't use 'nargout (modelfun)', because it doesn't work if
   'modelfun' is compiled as an oct-file or if it is an m-file
   function using (only) 'varargout'. I thought there is a Matlab
   option which indicates if 'modelfun' returns a second output (the
   Jacobian)? Can you check this option instead of using 'nargout()'?

Also, as a matter of style, I wouldn't name the last argument of
'computeJacob' 'p0', because this suggests 'initial parameters'. Just
'p' should be ok.

> >If a final Jacobian is returned, it should be computed in the same
> >way the algorithm computes its Jacobians, i.e. with __dfdp__.m as
> >default, jacobs.m if the option 'complex_step_derivative_f' is set
> >(which probably means 'never', since there is no equivalent option
> >in Matlab (?)), or the Jacobian function which was supplied by the
> >user, if any. The best way to achieve using the correct function for
> >the Jacobian is probably to call 'residmin_stat' with suitable
> >arguments; 'residmin_stat' is intended for this and similar things.
> 
> Initially, I was using residmin_stat (modelfun, x0, optimset
> (settings, "ret_dfdp", true)) but the Jacobian values were quite
> different from Matlab's. Now, I have used the value of solution (x)
> in place of x0. Is that ok?

Yes of course ... a reason for 'residmin_stat' to exist is that it
does not repeat the optimization, but uses the result of an
optimization.

If despite of now using the correct parameters there should still be
remarkable differences to Matlab, we should look for the reason.

> Here are the links for the updated code. Thank you.
> 
> https://github.com/AsmaAfzal/octave_workspace/blob/master/lsqnonlin.m
> https://github.com/AsmaAfzal/octave_workspace/blob/master/lsqcurvefit.m

A further matter of style: we usually prefer the C-like syntax
'n_out--;' or '--n_out' over 'n_out = n_out - 1;' in Octave (although
the advantage is negligible in the current case).

Overall, your 'lsqnonlin' looks quite well already. I have, however,
not checked the mapping of the output flags and the mapping of all
options. And the function should return its options if called as
'lsqnonlin ("defaults");' (there are examples for this in the existing
functions of optim and Octave).

I only roughly looked at 'lsqcurvefit', the code seems to be mostly
equivalent to that of 'lsqnonlin'. Note that I can not check if
'varargout{3} = curvefit_out{2}-in_args{4};' has the correct sign for
Matlab, but probably you have checked.

Regards,

Olaf

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

signature.asc
Description: Digital signature