Re: 3.1 status report

[Jaroslav Hajek]

On Wed, Jul 16, 2008 at 11:24 PM, John W. Eaton <address@hidden> wrote:
> 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.
>

gsl/multifit and gsl/multiroot essentially are the MINPACK algorithms
rewritten in C
(multiroot also contains "plain" newton and damped newton), so here
the work for 3a has already been done.
I see, however, a couple drawbacks:
1. most of GSL uses hard-coded double as the real type. Now that we
have true single precision, this is really a big drawback. I don't
reckon there are plans to change this state in GSL. And I can't see
any good way out of this.
2. the "core" linear algebra operation of the MINPACK algorithms
(trust-region Levenberg-Marquardt and Powell's hybrid method) is the
QRP factorization. GSL has its own QRP code (as well as other linear
algebra codes) and employs it here. I think, however, that LAPACK is
fairly better.

If we intend to make Octave based on GSL (i.e. map Octave's functions
to GSL where possible), then these issues will necessarily arise.


> jwe
>


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