Jaroslav Hajek wrote:
> On Sun, Mar 21, 2010 at 10:28 AM, David Bateman <[email protected]> wrote:
>
>> Michael Creel wrote:
>>
>>> 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.
>>>
>>>
>>>
>> Here is a code snippet that is needed to accept a function as the first
>> argument in an oct-file as a function handle or inline functio. String
>> functions are accepted and converted internally into an anonymous
>> function handle. The code then calls the function on an internally
>> created list of arguments and gets the results in another
>> octave_value_list.. If a string was passed, the internally created
>> function handle is cleared when you leave the oct-file..
>>
>>
>> octave_function *opt_fcn;
>> std::string fcn_name;
>>
>> .....
>>
>> if (args(0).is_function_handle () || args(0).is_inline_function ())
>> opt_fcn = args(0).function_value ();
>>
>
> Using function_value on a function handle is not the best idea,
> because that will ignore overloads of a named handle. It is better to
> call directly do_multi_index_op on the octave_value holding the
> handle. This works on inline functions, too.
>
This is what the Fquad, Feigs functions and probably others do.. So in
this case we need a better manner of handling functions passed to an
oct-file in an arbitrary manner.
>
>
>> else
>> {
>> fcn_name = unique_symbol_name ("__opt_fcn_");
>> std::string fname = "function y = ";
>> fname.append (fcn_name);
>> fname.append ("(x) y = ");
>> opt_fcn = extract_function (args(0), "mle_estimate", fcn_name,
>> fname,
>> "; endfunction");
>> }
>>
>> .....
>>
>> octave_value_list in_args;
>> in_args(0) = x;
>> octave_value_list out_args = opt_fcn->do_multi_index_op (1, in_args);
>>
>> ....
>>
>> if (fcn_name.length ())
>> clear_unction (fcn_name);
>>
>>
>
>
> I'd advise against doing this at all. It is not a good idea to inject
> identifiers into function scope, as these can potentially confuse you,
> and you may forget to clear them up. Besides, it will only allow a
> single parameter named x, and will conflict if you also want to allow
> passing a function name. I suggest you only allow the latter, and
> simply look up the function through the symbol table. Passing the body
> as a string has no advantages whatsoever over anonymous functions.
>
> Regarding the use of function_value, I advise you against doing it
> unless necessary and just work directly with octave_values instead.
>
>
Yeah I agree, but this allows the case of a function passed as a string
to be handled in a manner that is consistent with function handles.
--
David Bateman [email protected]
35 rue Gambetta +33 1 46 04 02 18 (Home)
92100 Boulogne-Billancourt FRANCE +33 6 72 01 06 33 (Mob)
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/octave-dev
