lør, 20 03 2010 kl. 19:36 +0100, skrev Michael Creel:
> I think that replacing list with cell arrays is pretty
> straightforward. I did that for samin and bfgsmin quite a while ago,
> when lists were deprecated. I suggest that the authors of the
> functions in question take care of this before Octave 3.4 appears. If
> they don't, then functions that stop working can be moved to a "deep
> freeze" directory, so that they can be recovered when someone has time
> to work on them.

This is fine by me.

The following functions seem to be using lists at the moment. Unless
they are fixed by the time Octave 3.4 is released, they will be put in a
directory that is not installed as part of the package.

        d2_min.m
        fminunc_compat.m
        line_min.m
        minimize.m
        nelder_mead_min.m
        test_d2_min_2.m
        test_d2_min_3.m
        test_fminunc_1.m
        test_min_3.m
        test_min_4.m
        test_minimize_1.m
        test_nelder_mead_min_1.m
        deriv.m
        optimset_compat.m
        __semi_bracket.m

So, if you care about any of these functions, please speak up.

> About requiring objective functions to accept only one argument, I
> don't think this is a good idea. There are situations where and
> objective function depends naturally on several things. An example is
> a statistical model, where there is the parameter to be estimated, the
> data, and perhaps special switches that influence the model, but are
> known ahead of time. If one contemplates two such statistical models,
> the data is the same, but the switches may change. When fitting the
> two models, it is useful to pass the name of the model as an argument.
> For these reasons, I find that an interface like
> myobj(x, data, name_of_model, switches_for_model) 
> is useful. Perhaps anonymous functions can achieve this in a
> convenient way, I'm not sure.

Yes, anonymous functions can deal with this problem. Imagine you have a
function that have this API

  function retval = posterior (data, model_params, prior_params)

where 'data' is some known matrix of observations and 'prior_params' is
a list of known parameters. The objective is then to optimise
'posterior' with respect to 'model_params'.

Now, assume you have the data in a matrix called 'X' and the prior
parameters in 'P', you can now create an anonymous function like this

  f = @(model_params) posterior (X, model_params, P);

You now have a one-parameter function that you can give to your
optimiser.

>  If mle_example.m in the Econometrics package could be rewritten using
> an anonymous objective function, that would be a helpful example.

I tried looking at this. To make it run, I had to fix a bug 'numhessian'
in 'optim'. Then, I removed a bunch of warnings generated by using
deprecated functions ('str2mat' has been replaced by 'char',
'poisson_rnd' by 'poissrnd', 'normal_cdf' by 'normcdf', ...). I commited
these changes.

When I got it running I actually couldn't figure out where you phrase
the optimisation problem. It looks like you do this in 'mle_estimate'
rather than 'mle_example. Is that right?

Essentially, you should be able to simply change

        if strcmp(method, "bfgs")
          [theta, obj_value, convergence, iters] = bfgsmin("mle_obj",
        {theta, data, model, modelargs, nslaves}, control);
        
into

        opt_fun = @(t) mle_obj (t, data, model, modelargs, nslaves);
        if strcmp(method, "bfgs")
          [theta, obj_value, convergence, iters] = bfgsmin(opt_fun,
        {theta}, control);

This, however, doesn't work as 'bfgsmin' requires the function to be
optimised to be given as a string.

>  IEven if it can be done, I'm not convinced that there are benefits to
> doing so, however. What is the advantage.

For me, the major advantage is that it simplifies the code and API of
the functions that actually does the optimisation. They can assume that
the function to be optimised only accept one input argument, i.e. they
don't have to deal with the extra input arguments.

Søren



------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev

Reply via email to