søn, 21 03 2010 kl. 09:32 +0100, skrev Michael Creel: > 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.
Okay, I checked in some stuff already, so you might get into conflicts. > I am interested in knowing what problem you found with numhessian. The main problem was the following line f_args(k); // resize only once which was used to resize the 'octave_value_list' used for inputs for the function being optimised. The idea in the above code is to touch the k'th element of 'f_args' such that it gets a certain size. However, since indexing is zero-based in C++, it is actually touching the k+1'th element. The number of input arguments to the function being optimised thus ended up being off by one, which resulted in an undefined default input argument. I changed the above code into f_args.resize (k); // resize only once Besides this, I also added checks for ensuring that the function actually returns 'double's. > 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. Actually, I think it would be fairly straight-forward. In '__bfgsmin.c' you only have to deal with anonymous functions. All the stuff with functions given as strings or similar can be dealt with in the 'bfgs.m' wrapper. > > 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. One problem with the current approach is that you currently can't use function handles with 'bfgs'. In some situations they are more simply to use than strings. I don't think you'll see any noticeable difference in terms of speed. I actually think you would be able to re-implement the entire function as an m-file without seeing much loss of speed, as usually most of the computation time is spend in the function being optimised rather than in the function doing the optimisation. 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
