On Sat, Mar 20, 2010 at 9:35 PM, Søren Hauberg <so...@hauberg.org> wrote:
> 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.
>
>
I have taken care of these warnings in my own code already. I'm planning on
checking it in once I have it adapted to use the openmpi_ext package. I am
interested in knowing what problem you found with numhessian.
> 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?
>
That's right. mle_estimate should be able to take theta, data, model and
modelargs and return the estimates.
>
> 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);
>
That looks pretty simple.
>
> This, however, doesn't work as 'bfgsmin' requires the function to be
> optimised to be given as a string.
>
Internally, __bfgsmin.c uses feval to compute the function value. Perhaps
that could be changed to work with anonymous functions. I think that this
would be the hardest part of making the change.
>
> > 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.
>
I'm not so sure that this matters too much, given that the code is already
written and pretty well tested. If there were an efficiency improvement,
then I would be convinced.
Thanks for looking at this.
Michael
>
> 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
