On Sun, Mar 21, 2010 at 7:38 PM, David Bateman <dbate...@dbateman.org> wrote:
> Jaroslav Hajek wrote:
>>
>> On Sun, Mar 21, 2010 at 10:28 AM, David Bateman <dbate...@dbateman.org>
>> 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.
>
I fixed this in cellfun (in fact it still works, but gives a warning).
The same stub was also in bsxfun; however, the function-body-as-string
part was not functional (bsxfun needs a binary function), so I removed
it entirely. Besides being limited to one argument named x, it also
caused problems when you wanted to pass in a function name, because
e.g. passed "myfun" got internally transformed to
function y = __cellfun_fcn__ (x) myfun; endfunction
which unfortunately doesn't work. I think passing the string "sin(x)"
has no advantage at all over passing @(x) sin(x) or @sin,
in fact the string version is worse because the string needs to be
parsed at each call, whereas anonymous function bodies are parsed at
the time they're loaded.
Regarding the quad et al. functions, it's on my list, but that's a lot
of dull work. I believe it's less important here, because I think
overloaded handles are not typically passed to such functions (unlike
cellfun, which is a much more general tool).
Extracting the (octave_function *) pointer just for calling a function
is another potentially dangerous idiom that I think is mostly useless,
because do_multi_index_op and do_index_op can be called directly on
the octave_value and don't require messing up with pointers.
>
> 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.
>
I supposed it was stuff that predated function handles. I certainly
consider it obsolete. I don't see why the functions should support
this form at all. If you create the string at the point of the call,
you can as well create an anonymous function, which is also more
efficient:
quad ("sin(x)", ...) --> quad (@(x) sin(x), ...)
even if the string is a variable (which I think is very rare), you can
still use "inline":
F = "sin(x)";
quad (F, ...) -> quad (inline (F, "x"), ...)
--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
------------------------------------------------------------------------------
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
