Optimization : bfgs and cg_min

[Etienne Grossmann-5]

  Hello,

this is to ask the opinion of Octave-Forge developers and users on
what to do about the optimization functions :

  My opinion is to replace the bfgs.m and nrm.m files so that the new
bfgs() function takes the same parameters as the actual cg_min(), and
remove this last function.

  I have verified on various quadratic programming cases and initial
positions that my modified bfgs2() executes the same algorithm, in the
same time (no extra overhead) as the original bfgs(). In terms of
speed, it is thus much quicker than cg_min(). In terms of flexibility,
it is better than bfgs(), since it can optimize wrt to any (not just
the 1st) argument, and the termination criterion can be tweaked.

  Another difference with the original bfgs(), which may be either an
advantage or a pain, is that it requires the derivatives of the
function to be provided by the user. This is an advantage because, if
a hand-made derivative is available, it can be used instead of the
numerical differentiation. This has the slight disadvantage that, if
you want to use numerical differentiation, you should provide the
function yourself, e.g. with cdiff().

  So, if people who use bfgs() right now do not mind changing the way
this function is called, I think it would be a good idea to substitute
it and remove cg_min.m, which would then be redundant.

  Opinions?

  Cheers,

  Etienne

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[Etienne Grossmann-5]

<only Paul>
  Hi Paul

<only Ben>
  Hi Ben

<only sf>
  Hi Octave-Smiths

</only>
  I've worked a little bit on "some sort of a preprocessor" that
allows to maintain many .m files with a single template. The idea is
that many functions with different synopsis and nearly the same
internals would be easier to maintain :

>From pkienzle@... Fri Apr 19 19:36:53 2002

# Maybe we could have three separate internal routines, one for each case?
# If you want to go that route, I suggest keeping a single source file with
# some sort of preprocessor markup and use make to generate the actual
# functions that get installed.  I don't think we can use the C preprocessor
# because it needs to understand identifiers and strings, so we would have to
# invent our own.  I know people have done matlab preprocessors in the past
# (me included) but I can't find any links at the moment.

  The preprocessor, called 'fsplit' (you suggest a better name if you
like) is really simple. If you put this mail run in a file foo.tpl and
and do

  fsplit foo.tpl

it will produce files 'foo_Paul.txt', 'foo_Ben.txt' and
'foo_sf.txt'. When it finds a tag

<only sf>

All that follows (until the next <only> or </only> tag) goes into the
file foo_sf.txt.

<only Ben, Paul>

Now, this will go to 'foo_Paul.txt' and 'foo_Ben.txt'.

</only>

And this will go to all files.

The name of the input file is trimmed by removing the old suffix,
which is indicated by

<oldsuffix tpl>

The suffix of the new files is indicated by the <newsuffix> tag, like

<newsuffix txt>

Now, of course, for .m files, one will want <newsuffix m>. Note that
tags that are not at the beginning of the line are ignored, so that
I can write <newsuffix whatever_I_like>, the suffix is still .txt.

  And that's it.

  Does this sound like useful stuff?

  Etienne

--
Etienne Grossmann ------ http://www.isr.ist.utl.pt/~etienne

[Etienne Grossmann-4]

  Sorry, this mail was meant forthe octave-forge mailing list.

  Etienne