[Octave-bug-tracker] [bug #60237] Differente behaviour in anonymous function handling

[Denis Sbragion]

Follow-up Comment #9, bug #60237 (project octave):

Some further investigations, which, to tell the truth, didn't make the
situation completely clear to me. I changed the callback oct file to the
following one:


#include <octave/oct.h>
#include <octave/parse.h>

DEFMETHOD_DLD (callback, interp, args, nargout, "Callback Demo")
{
        int nargin = args.length ();

        if (nargin < 2)
                print_usage ();

        octave_value_list newargs;

        for (octave_idx_type i = nargin - 1; i > 0; i--)
                newargs(i-1) = args(i);

        octave_value_list retval;       
        
        if (args(0).is_function())
                octave_stdout << "is_function\n";
                
        if (args(0).is_function_handle())
                octave_stdout << "is_function_handle\n";
                
        if (args(0).is_inline_function())
                octave_stdout << "is_inline_function\n";
                
        // Works with 6.2.X, doesn't compile with 5.2.0
        // retval = interp.feval (args(0), newargs, nargout);
        
        // Fails with the anonymous function on 6.2.X, doesn't compile with 
5.2.0
        // retval = interp.feval (args(0).function_value(), newargs, nargout);
        
        // Works with 6.2.X, doesn't compile with 5.2.0
        // retval = octave::feval (args(0), newargs, nargout);
        
        // Fails with the anonymous function on 6.2.X, works with 5.2.0
        // This is the way NLOpt works
        // retval = octave::feval (args(0).function_value(), newargs, nargout);
        
        // Works with 6.2.X and 5.2.0
        octave_value arg0 = args(0);
        retval = octave::feval (arg0, newargs, nargout);

        return retval;
}


I tested it on 6.2.0 with the following Octave code:


function antest()
        b = 2;  
        
        function r = sdot(a)
                r = dot(a,b);
        endfunction
        
        callback(@sdot,3)
        
        af = (@(a)(dot(a,b)));
        
        callback(af,3)
endfunction


This doesn't work on 5.2.0, because handles to nested functions aren't
supported, so under 5.2.0 it has been tested only with the anonymous
function.

First of all, only ".is_function_handle()" is true, both with the nested
function and the anonymous function. Furthermore interp.feval isn't available
under 5.2.0, which forces the use of octave::feval to get the code working
both under 5 and 6.

With the nested function under 6.2.0 it always works. With the anonymous
function it works only when feval is called with an octave_value. To do the
same under 5.2.0 you have first to assign the octave_value to a local
variable, else there's some const qualifier clash and it doesn't compile.

The call method at the end of the code works both with 6.2 and 5.2. My
conclusion is that feval should be called only with an octave_value, leaving
Octave the task to sort out which kind of function it has to deal with. It
isn't a problem with NLOpt, but I wonder if this is a good thing performance
wise when the function type is known in advance and feval has to be called an
huge number of times with fast simple functions.

The need to copy to a local variable under 5.2.0 is just to circumvent a quirk
of 5.2.0 which has been fixed in 6.2. Other ways to call feval are just a
legacy of older versions of Octave and shouldn't be used anymore.

If someone can confirm that all of this is correct I'll modify the NLOpt
interface to follow the current policy, else let me know which is the way to
go.

My impression is that there's some mix of different approaches in the current
Octave code, which is in the process of being sorted and cleaned up, but just
looking at the code isn't clear in which direction it is going, so any hint is
appreciated.

Bye,

Denis Sbragion

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60237>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/