Re: 3.1 status report

[John W. Eaton]

On 16-Jul-2008, Jaroslav Hajek wrote:

| >  10. Improve compatibility of fsolve
| >        - input/output args should be compatible
| >        - use optimset for options
| >
| 
| I started to work on this, as well as adding/porting other functions
| (fzero, lsqnonlin etc).
| But I caught some rumors about 4. (moving optimization to OctaveFOrge
| package) and I stopped until this is resolved. Personally, I'd vote
| for having the basic nonlinear optimization/least squares/root finding
| directly in Octave.

I agree that Octave should have some general-purpose optimization
and root finding functions included by default.

| To be more constructive, I propose:
| 
| 1. Update optimset to be reasonably Matlab-compatible (differences are
| unavoidable due to different algorithms employed)
| 
| 2. Port the 1-dimensional funcs fzero and fminbnd from octave-forge,
| possibly update.
| 
| 3a. Include the rest of MINPACK (currently used for fsolve) to
| implement lsqnonlin. Also modify the MINPACK drivers to reverse
| communication so as to make the functions reentrant.
| OR
| 3b. Implement fsolve and lsqnonlin drivers as m-files, possibly
| wrapping the MINPACK step selection subprograms and reusing them.
| More work, but probably a more maintainable and extendable outcome.
| 
| 4. improve lsqnonneg using the QR updating funcs (they can also be
| used for the Powell hybrid method in fsolve).

These all seem OK to me.  If you are writing the code, then I think it
is up to you to choose between 3a and 3b.  Does GSL have a C
translation of the Minpack algorithms?  If so, maybe we could use
those.  If we choose that, then item 3 could perhaps be postponed to
3.4, when I expect including GSL functions should be on the TODO list.

jwe