octave-dev

[OctDev] plans for bfgsmin and related cleanup

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

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

1) All input checking will be in the .m file frontend. Thus, it will be 
possible to crash octave by directly calling __bfgsmin with bad 
arguments. Is that acceptable?

2) bfgsmin.cc currently uses newtonstep.cc which sometimes calls 
bisectionstep.cc. I wrote the two stepsize algorithms as separate 
functions since they could be of use by other minimization algorithms. 
But I'm not aware of any such use, so I'm thinking of incorporating them 
into __bfgsmin.cc, so that they would benefit from the argument checking 
in the new bfgsmin.m.  Does anyone object to the two stepsize functions 
disappearing from general availability?

3) bfgsmin.cc currently has stuff like
(line 391)	g = tempmatrix.row((octave_idx_type)0).transpose();
in it which prevent it from compiling using "mkoctfile bfgsmin.cc"
I understand this is for 64 bit compatibility. This is no big deal for 
me, I'm ok using octave-forge. But is it possible to get 32 and 64 bit 
compatibility and still compile using plain mkoctfile?

4) I'm planning similar changes for numgradient and numhessian, and the 
disappearance of finitedifference. Comments welcome.

Thanks, Michael

Re: [OctDev] plans for bfgsmin and related cleanup

[Bill D. <de...@se...>]

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?

> 1) All input checking will be in the .m file frontend. Thus, it will be 
> possible to crash octave by directly calling __bfgsmin with bad 
> arguments. Is that acceptable?

My personal opinion is that every function should do full error checking 
of its arguements.  I know that people are writing web front-ends to 
octave, and that could lead to dangerous code.

The way that I view this is that some day, someone will call __bfgsmin and 
get an error and complain about it.  Then we'll have to add the arguement 
checking anyway, so it should just be added from the beginning.

Bill

-- 
"The history of liberty is a history of the limitation of government
power, not the increase of it."
   -- Woodrow Wilson

Re: [OctDev] plans for bfgsmin and related cleanup

[Etienne G. <et...@cs...>]

  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).

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).

Is my guess close?

  Etienne

# >1) All input checking will be in the .m file frontend. Thus, it will be 
# >possible to crash octave by directly calling __bfgsmin with bad 
# >arguments. Is that acceptable?
# 
# My personal opinion is that every function should do full error checking 
# of its arguements.  I know that people are writing web front-ends to 
# octave, and that could lead to dangerous code.
# 
# The way that I view this is that some day, someone will call __bfgsmin and 
# get an error and complain about it.  Then we'll have to add the arguement 
# checking anyway, so it should just be added from the beginning.
# 
# Bill
# 
# -- 
# "The history of liberty is a history of the limitation of government
# power, not the increase of it."
#   -- Woodrow Wilson
# 
# 
# 
# -------------------------------------------------------
# This SF.Net email is sponsored by xPML, a groundbreaking scripting language
# that extends applications into web and mobile media. Attend the live webcast
# and join the prime developer group breaking into this new coding territory!
# http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
# _______________________________________________
# Octave-dev mailing list
# Oct...@li...
# https://lists.sourceforge.net/lists/listinfo/octave-dev

-- 
Etienne Grossmann ------ http://www.cs.uky.edu/~etienne

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

Re: [OctDev] plans for bfgsmin and related cleanup

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

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?

Simplicity and code re-use: All the C functions would have their 
arguments checked in the same place. As it is, there's more scope for 
programmer error since there are multiple copies of essentially the same 
argument checks.

Extendability: Someone writing a different frontend to __bfgsmin (for 
example, a general minimization routine that allows the method to be 
user selected) would have intelligible Octave expressions for argument 
checks to use as an example, rather than the less user friendly C 
argument checks.

> 
>> 1) All input checking will be in the .m file frontend. Thus, it will 
>> be possible to crash octave by directly calling __bfgsmin with bad 
>> arguments. Is that acceptable?
> 
> 
> My personal opinion is that every function should do full error checking 
> of its arguements.  I know that people are writing web front-ends to 
> octave, and that could lead to dangerous code.
> 
> The way that I view this is that some day, someone will call __bfgsmin 
> and get an error and complain about it.  Then we'll have to add the 
> arguement checking anyway, so it should just be added from the beginning.

Well, that's the way it is now, so if this is not a well-received idea, 
the course of action is clear :-) Thanks for the input.

M.