names in multimin section

names in multimin section

[Giulio Bottazzi]

Hi all,

I think that in a couple of cases the names in the multimin section
are a little bit inconsistent (or, at least, hard to remember...).

First: if the function with derivatives is of type

gsl_multimin_function_fdf

then one expects the type of the function without derivatives to be

gsl_multimin_function_f

rather than gsl_multimin_function.


Second: the present value of the objective function is stored in the
variable "f" of the structure "gsl_multimin_fdfminimizer" but in the
variable "fval" of the structure "gsl_multimin_fminimizer".


Bye,
	Giulio.

Re: names in multimin section

[Ivo Alxneit-Kamber]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

On Tue, 2006-02-28 at 15:39 +0100, Giulio Bottazzi wrote:
> Hi all,
> 
> I think that in a couple of cases the names in the multimin section
> are a little bit inconsistent (or, at least, hard to remember...).
> 
> First: if the function with derivatives is of type
> 
> gsl_multimin_function_fdf
> 
> then one expects the type of the function without derivatives to be
> 
> gsl_multimin_function_f
> 
> rather than gsl_multimin_function.

i tend to agree here (see my previous post on the modified
initialization of nm_simplex), but i think we might get along using ONLY
gsl_multimin_function_fdf i.e. only one type of function. if a minimizer
does not use gradients you could set void * df and void * fdf to a NULL
pointer (or leave it, it is never been used). currently only nm_simplex
falls into the latter category (i do not know of any other algorithm
that does not make use of derivatives, but we should check before we
make any changes here to make sure it will not break in the future).
with this change the interface would be simpler.

in a way we have the same situations for the ODE solvers. only one type
of function that includes the jacobian but some minimizer do not use it
and you can pass a NULL pointer there.
> 
> 
> Second: the present value of the objective function is stored in the
> variable "f" of the structure "gsl_multimin_fdfminimizer" but in the
> variable "fval" of the structure "gsl_multimin_fminimizer".

should be fixed.

> 
> 
> Bye,
> 	Giulio.
-- 
Dr. Ivo Alxneit
Laboratory for Solar Technology   phone: +41 56 310 4092
Paul Scherrer Institute             fax: +41 56 310 2688
CH-5232 Villigen                   http://solar.web.psi.ch
Switzerland                   gnupg key: 0x515E30C7


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: names in multimin section

[Brian Gough]

Giulio Bottazzi writes:
 > Hi all,
 > 
 > I think that in a couple of cases the names in the multimin section
 > are a little bit inconsistent (or, at least, hard to remember...).
 > 
 > First: if the function with derivatives is of type
 > 
 > gsl_multimin_function_fdf
 > 
 > then one expects the type of the function without derivatives to be
 > 
 > gsl_multimin_function_f
 > 
 > rather than gsl_multimin_function.
 > 
 > 
 > Second: the present value of the objective function is stored in the
 > variable "f" of the structure "gsl_multimin_fdfminimizer" but in the
 > variable "fval" of the structure "gsl_multimin_fminimizer".

I agree it's a bit inconsistent, unfortunately it's difficult to
change these things once the library is released. Generally I prefer
not to break the API as I get tired when other libraries do that
unnecessarily.

There are the functions gsl_multimin_fdfminimizer_minimum and
gsl_multimin_fminimizer_minimum in this case, so the actual values in
the struct are less important.

-- 
Brian Gough

Re: names in multimin section

[Brian Gough]

Ivo Alxneit-Kamber writes:
 > i tend to agree here (see my previous post on the modified
 > initialization of nm_simplex), but i think we might get along using ONLY
 > gsl_multimin_function_fdf i.e. only one type of function. if a minimizer
 > does not use gradients you could set void * df and void * fdf to a NULL
 > pointer (or leave it, it is never been used). currently only nm_simplex
 > falls into the latter category (i do not know of any other algorithm
 > that does not make use of derivatives, but we should check before we
 > make any changes here to make sure it will not break in the future).
 > with this change the interface would be simpler.

It should be simple enough to switch between an fdfminizer and
fminimizer function by copying the three elements of the struct.

While it's true that odeinitval doesn't distinguish between the two
cases of with/without jacobian, it's an exception to the main scheme
in the design document ("Minimal Structs").  

Passing a null value for the jacobian is a just suggested as trick
that happens to work, not really part of the design.

-- 
Brian Gough