On Mon, Aug 03, 2009 at 01:07:23PM +0200, Olaf Till wrote: > I don't know if there are theoretical objections against bounds in > Levenberg-Marquardt optimization, but I also ended up introducing > bounds into leasqr for my use; I would think this is general > purpose.
Sorry, I remember now that there were some problems. Often, a bound is desirable because some parameters do not produce useful results (of the user function) outside a certain range (e.g. a division by zero might occur). In such a case, the bounds should already be respected during gradient determination, not only later in the 'step'. This would mean that if a parameter is already at its bound, only a _one_-sided gradient can be computed for this parameter, but only on the 'side' away from the bound. Also, in two-sided bounds, the possible parameter-change for gradient estimation could become small (too small for some problems?). Since currently gradient estimation in leasqr is done by different function (dfdp), which knows nothing on bounds, implementation is not so easy. One could pass the bounds-argument also to dfdp, but there might exist user-replacements for dftp (there is an argument to leasqr just to choose this function) which do not honour the 'bounds' argument ... so people can not expect bounds to work without changing their dfdp-replacement. Olaf ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Octave-dev mailing list Octave-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/octave-dev
