On 7/23/09 Jaroslav Hajek wrote: >> BTW, I find it confusing that optimization functions are split >> between >>> Octave and the octave-forge package. At one point, I thought >>> there was a plan to keep associated functions together, either >>> all in Octave or in the appropriate octave-forge package. I >>> guess the split remains more development oriented: polished >>> functions make it to Octave where as rough contributions remain >>> in octave-forge. >>> >>> > > Er, not really. Yes, the dev status is a factor; for instance, source > must conform to Octave guidelines. However, it's also about what is > more and what is less common. For instance, you have linear algebra > in the core, but you also have other advanced linear algebra in > packages. It's the same with optimization; I don't see what's > confusing on that. > > My intent was to bring to core Octave the 1D equation solver / > optimizer (fzero / fminbnd) and the local unconstrained > solver/optimizer (fsolve / fminunc). These both use established > techniques - bracketing + inverse interpolation in 1D, and local > Newton/BFGS iterations with trust-region step limiting and factorized > updating (Broyden/BFGS). There's a lot of similarity between the > fsolve and fminunc code. Both are designed for small-to-medium-size > problems (they use full matrices), and are local iterative methods. > Starting from a sufficiently good initial guess, with a smooth, > reasonably behaved problem, these methods will probably work well. > > The optim package, on the contrary, should provide a variety of other > methods, for expert usage and more difficult problems, with > bound/linear/equality/inequality constrants, noisy functions, etc. It > is believed amongst numerical analysts that there is no single best > method, so there's no problem if optim contains competing methods. > > I encourage you to use the fminunc from core if local unconstrained > search is enough for your purposes. So far it didn't get much > testing, so don't be too surprised if problems arise, but I hope it > will improve over time, when real usage is seen.
OK, seems reasonable. Are you planning to move fminbnd over to Octave sometime soon? I am rather pragmatic and can work with this approach. However, let me make a couple points you might consider. Matlab provides all of its optimization functions in the optimization toolbox; none are provided in core Matlab. I am sure they do this for monetary reasons (to sell more overpriced toolboxes), but folks migrating to Octave might get a little confused. Also, some of the Matlab optimization functions, e.g. fminunc, are not algorithm specific. The algorithm used depends on a passed option and/or the nature of the problem (detected internally by the function). This was sort of the philosophy used for the old fminunc in octave-forge. If we wanted to emulate this behavior, and I personally like the idea, then all the supported algorithms would need to be co-located with the fminunc function. Anyway, that's my 2 cents. Jonathan ------------------------------------------------------------------------------ _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
