Re: uniform random variable in oct file?

[Michael Creel]

On 9/11/06, John W. Eaton <address@hidden> wrote:

On 10-Sep-2006, Michael Creel wrote:

| On 9/9/06, Paul Kienzle <address@hidden> wrote:
| >
| >
| > 4. Define a c function which can call back into the scripting
| >     language.  This is useful if the user passes a scripted
| >     objective function rather than one implemented in C.
| >
| >     double scriptcall(int n, const double p[], void *data);
| >     a. convert n,p into a vector v in the scripting language
| >     b. cast data into function type fn in the scripting language
| >     c. call fn with v using feval in the scripting language
| >     d. if the script function raised an exception return inf
| >        otherwise convert the script return value into a c double
| >        and return it
|
| I'm still just not clear about all of this, but maybe I should make it clear
| that my goal is to come up with an efficient minimizer for objective
| functions defined as .m files. Objective functions written as .oct files
| should also be supported. Currently, bfgsmin.m and samin.oct achieve this
| goal. They do this using feval() to evaluate the objective function (using
| celleval.oct). I would like to eliminate the feval, if possible,

If you want things to work properly, then I think your best bet is to
use feval.  That will allow both  .m files and .oct files to be found
by the normal lookup methods, and new versions of the functions are
found automatically if they are edited by a user between runs of your
function.

If there is a better (or at least more efficient) method than feval,
then I think we should formalize it in some way so that it is easy to
use and documented.  I don't like anything that uses do_multi_index_op
very much because I still think of that as an internal function of
Octave that may change.  If you rely on that function, then you should
not be too surprised if your code needs to be updated to continue
working with some future version of Octave.

jwe

I'll stick with feval. I thought perhaps there was some low hanging fruit that could give a good speedup, but I guess not. For optimization, where feval is called so many times, any speedups there would have an important effect. Thanks, M.