Re: 3.1 status report

[Jaroslav Hajek]

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

I'd tend to leave the general multidimensional optimization codes like
fmins, bfgs etc. in Octave Forge. Many algorithms exist in this area
with no clear winner for Octave, IMHO.

all of the above seems futile if the long-term goal is to move the
optimization funcs away from core Octave, so I'd appreciate if more
people vote for this plan before I resume the work.

cheers


-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz