[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 3.1 status report
From: |
John W. Eaton |
Subject: |
Re: 3.1 status report |
Date: |
Wed, 16 Jul 2008 17:24:24 -0400 |
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