Re: [OctDev] plans for bfgsmin and related cleanup

[Michael C. <mic...@ua...>]

Etienne Grossmann wrote:
>   Hi All,
> 
> On Wed, Mar 22, 2006 at 07:52:28AM -0500, Bill Denney wrote:
> # On Wed, 22 Mar 2006, Michael Creel wrote:
> # 
> # >Hello all,
> # >I'm planning on converting the existing bfgsmin (source bfgsmin.cc) to a 
> # >new function __bfgsmin (source __bfgsmin.cc), and writing a user frontend 
> # >bfgsmin.m. A couple of questions
> # 
> # What is the benefit of doing this?
> 
> my guess:
> 
> 1) Having a user-friendly func (.m) where the user-friendliness is
>    written in Octave (ez on the developer).

This is what I was thinking about.

> 
> 2) Having a low-overhead func (__.cc) that you may use to do N>>1
>    times almost the same thing, without paying N*overhead. This is
>    only useful if you can actually determine the params for __.cc
>    (perhaps if bfgs.m has a "show_me_how_to_do_it" options that
>    returns the args it passes to __bfgs.cc).

This is something that I hadn't thought about, but may be a benefit, Now 
  when bfgsmin calls newtonstep, about a zillion times during the course 
of minimization, the arguments are checked each time. How important the 
arg checking overhead is, I have no idea. But it can be eliminated with 
or without going the .m file frontend route, just by incorporating the 
stepsize algorithm into bfgsmin.cc. Actually, now that I think about it, 
I can incorporate a copy of the numeric gradient code into bfgsmin, too.
There's no need to make them disappear as separate  genrally available 
functions, the same functions will just have different names internally 
to bfgsmin.cc. This will get rid of a lot of overhead and will achieve 
the benefit of a single pass though argument checking for all functions.

For a first step, I'm going to try that and do some benchmarking. The 
issue of a m-file frontend can wait or be forgotten.

Thanks, M