bugGNU Octave - Bugs: bug #60237, Differente behaviour in anonymous...

 
 

bug #60237: Differente behaviour in anonymous function handling

Submitted by:  Denis Sbragion <dsbragion>
Submitted on:  Mon 15 Mar 2021 04:33:16 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  6.2.0 Operating System:  Any

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Mon 05 Apr 2021 04:23:21 PM UTC, comment #32: 

Results with Matlab R2021a:

>> bug60237
    20     3    21     4

    20     3    21     4

    20     3    21     4

    20     3    21     4

    20     3    21     4

>>

Closing as fixed again.

Markus Mützel <mmuetzel>
Project Member
Sun 04 Apr 2021 11:57:09 AM UTC, comment #31: 

I attached bug60237.m that contains some test cases. With the current tip it results in:

   20    3   21    4
   20    3   21    4
   20    3   21    4
   20    3   21    4
   20    3   21    4

Hope that the same result will be produced by MATLAB.

(file #51188)

Anonymous
Fri 02 Apr 2021 05:59:09 PM UTC, comment #30: 

Re: comment #29. Thanks, That was possibly my wrong understanding about the expected mechanism of handle to functions as a non-beginner MATLAB/Octave user. Thanks for clarification!

Anonymous
Fri 02 Apr 2021 05:43:38 PM UTC, comment #29: 

Re: comment #28: No, the anonymous function handle itself captures the stack frame(s) that are active at the time the anonymous function handle expression is evaluated.  It does not convert any part of the expression that makes up the body of the anonymous function to be function handles.  You can check this for yourself by looking at the patches that I pushed.

John W. Eaton <jwe>
Project Administrator
Fri 02 Apr 2021 05:37:59 PM UTC, comment #28: 

Re: comment #27. I agree with that. But the case in comment #25 is different issue:
It seems that if a nested function (that captures mutable variables by reference) is called form an anonymous function (that captures immutable variables by value) it is converted to a handle to a nested function (that captures mutable variables by value).
So the expression `r = @() bm (a);` is treated as `r = @() (@bm) (a);` as the result of test case in comment #25 results in [2 3]. That is very interesting!

Anonymous
Fri 02 Apr 2021 05:15:39 PM UTC, comment #27: 

Re: comment #25: Another way of looking at it is that anonymous functions are just another way of writing a nested function that have the following special features:

The body of the function may contain only a single expression, no statements.  In Matlab, assignments are statements while in Octave they are expressions.  But in anonymous functions, Octave also disallows assignment expressions.

Unlike ordinary nested functions, anonymous functions also capture variable values from the parent scope when the anonymous function statement is evaluated.

But otherwise, they also capture the parent stack frame(s) just as handles to nested functions do.

John W. Eaton <jwe>
Project Administrator
Fri 02 Apr 2021 05:11:32 PM UTC, comment #26: 

I believe we can close this report as fixed.

Markus Mützel <mmuetzel>
Project Member
Fri 02 Apr 2021 05:00:50 PM UTC, comment #25: 

Very interesting!? The expression

r = @() bm (a);

is treated as:

r = @() (@bm) (a);

Thanks!

Anonymous
Fri 02 Apr 2021 04:51:47 PM UTC, comment #24: 

Yes, it should. And it does.

Markus Mützel <mmuetzel>
Project Member
Fri 02 Apr 2021 04:44:09 PM UTC, comment #23: 

Interesting! My opinion was that when f() is called 'd' is out of scope. Possibly this should produce [2 3] :

function r = bug_60237 ()

  f = ancall (2);

  r = [f(), f()];

end


function r = ancall (a)

  d = 2;

  function c = bm (a)

    c = d;

    d = d+1;

  end

  r = @() bm (a);

end

Anonymous
Fri 02 Apr 2021 04:42:11 PM UTC, comment #22: 

Hello John,

thanks, so it is as I suspected. I'll fix the NLOpt interface to follow the new approach and warn back the NLopt developer about the change.

And of course I really want to thank you and all the Octave team for this great software, which is getting better and better.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Fri 02 Apr 2021 04:34:42 PM UTC, comment #21: 

Denis: I want to remove the function_value methods from octave function handle class because it can't always return something useful as function resolution may be required to happen when calling a the function through the handle rather than when the function handle is created.  That requirement was not apparent N years ago when Octave and Matlab did not have classes and function resolution worked differently.  I probably should have deprecated that interface in version 6.  You should just pass the octave_value object to feval and let it do the function lookup.

John W. Eaton <jwe>
Project Administrator
Fri 02 Apr 2021 04:32:59 PM UTC, comment #20: 

That is a syntax extension that doesn't work in Matlab. I used the following test case instead:

function r = bug_60237 ()

f = ancall (2);

r = f() + 1;

end


function r = ancall (a)

d = 2;

function c = bm (a)

c = a + d;

end

r = @() bm (a);

end

Results in Matlab R2021a:

>> bug_60237

ans =

     5

Same result with a current tip.

Again: "bm" is a nested function and shares its scope with the containing function.

Markus Mützel <mmuetzel>
Project Member
Fri 02 Apr 2021 04:27:54 PM UTC, comment #19: 

Ooos, I missed brackets, Thanks!

function r = bug_60237 ()

  r = ancall (2)() + 1;

endfunction


function r = ancall (a)

  d = 2;

  function c = bm (a)

    c = a + d;

  endfunction;

  r = @() bm (a);

endfunction

Anonymous
Fri 02 Apr 2021 04:21:50 PM UTC, comment #18: 

Yes, that fails. But for a completely unrelated reason.
In Matlab R2021a:

>> bug_60237
Operator '+' is not supported for operands of type 'function_handle'.

Error in bug_60237 (line 3)
r = ancall (2) + 1;

Equivalent error in Octave:

>> bug_60237

error: binary operator '+' not implemented for 'function handle' by 'scalar' operations
error: called from
    bug_60237 at line 3 column 3

Markus Mützel <mmuetzel>
Project Member
Fri 02 Apr 2021 04:16:40 PM UTC, comment #17: 

Oh sorry and Thanks! I wrongly read the test case as the following that should produce error:

function r = bug_60237 ()

  r = ancall (2) + 1;

endfunction


function r = ancall (a)

  d = 2;

  function c = bm (a)

    c = a + d;

  endfunction;

  r = @() bm (a);

endfunction

Anonymous
Fri 02 Apr 2021 03:57:50 PM UTC, comment #16: 

In Matlab R2021a:

>> bug_60237

ans =

     5

"bm" is a nested function. So, afaict it should share the complete scope with the "containing" function.

I see the same result with hg id af41ebf3d1b3.

Markus Mützel <mmuetzel>
Project Member
Fri 02 Apr 2021 03:46:08 PM UTC, comment #15: 

Hello,
I'm not sure ,as I don't have access to MATLAB, but I think the following test that is contained in the change set should produce error in MATLAB. Because '@(a) bm (a)' doesn't capture 'd'. When calling 'ancall' it should say that "error: 'd' is undefined".

function r = bug_60237 ()

  d = 2;

  function c = bm (a)

    c = a + d;

  endfunction;

  r = ancall (@(a) bm (a), 2);

endfunction


function r = ancall (f, a)

  r = f (a) + 1;

endfunction

Anonymous
Fri 02 Apr 2021 10:28:16 AM UTC, comment #14: 

Hello John,

tested with octave-2021-04-02-00-31-w64.

The problem with the pure Octave example of comment #10 now has gone and it works.

It still doesn't work with the callback oct file of comment #9 when the callback function is called the same way NLopt uses, i.e.:

retval = octave::feval (args(0).function_value(), newargs, nargout);

I tested also the other callback methods and it looks like the behaviour with oct files hasn't changed, so of course it still doesn't work with NLopt either. As I explained, I don't know if this should be considered a bug or just a change in the way the API should be called.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Thu 01 Apr 2021 07:55:56 AM UTC, comment #13: 

Thanks, going to test it ASAP.

Denis Sbragion <dsbragion>
Thu 01 Apr 2021 07:37:43 AM UTC, comment #12: 

I pushed a series of changes on stable to fix this problem for nested and anonymous functions:

http://hg.savannah.gnu.org/hgweb/octave/rev/0574c36a095e
http://hg.savannah.gnu.org/hgweb/octave/rev/c74ff452e2bb
http://hg.savannah.gnu.org/hgweb/octave/rev/34d06c73b48d

These changesets make changes in public interfaces, which is something that we try to avoid during a stable release series.  OTOH, they are important to make handles to nested and anonymous functions work properly.  And since handles to nested functions were one of the big new features of Octave 6, I'm in favor of making this change in version 6 even if it causes some (small) backward compatibility issues.  These interfaces are not something that typical users (even those who write .oct files) will encounter.

John W. Eaton <jwe>
Project Administrator
Mon 22 Mar 2021 06:13:59 PM UTC, comment #11: 

The problem described in comment #10 is related to bug #60137 but not exactly the same.

I have a fix in progress that will allow the following to work:

function antest()
        d = 2;

        function c = bm(a)
                c = a + d;
        endfunction;

        ancall(@bm,2)
endfunction

function r = ancall(f,a)
        r = f(a) + 1;
endfunction

but the added level of indirection with the anonymous function handle exposes another issue.

John W. Eaton <jwe>
Project Administrator
Mon 22 Mar 2021 03:45:48 PM UTC, comment #10: 

After some further testing I found a pure Octave test case where Octave 6.2 fails and 5.2 works. No oct file involvment.

The following code:

function antest()
        d = 2;

        function c = bm(a)
                c = a + d;
        endfunction;

        ancall(@(a)(bm(a)),2)
endfunction

function r = ancall(f,a)
        r = f(a) + 1;
endfunction

Works with 5.2.0, while with 6.2.0 and 6.2.1 gives:

octave:3> antest
error: 'd' undefined near line 5, column 5
error: called from
    antest>bm at line 5 column 5
    antest>@<anonymous> at line 8 column 14
    antest>ancall at line 12 column 4
    antest at line 8 column 2

Denis Sbragion <dsbragion>
Thu 18 Mar 2021 11:21:30 AM UTC, comment #9: 

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

Denis Sbragion <dsbragion>
Thu 18 Mar 2021 06:50:26 AM UTC, comment #8: 

comment #7:

> What's weird is that, if I understand the Octave code correctly,

...

I was wrong here. Looking better, the Octave code for feval threat ".is_function()" and "is_function_handle()" in two different ways. Need further investigations to understand what's going on.

Denis Sbragion <dsbragion>
Wed 17 Mar 2021 07:01:25 PM UTC, comment #7: 

Hello Markus,

comment #6:
...

> I'd guess that `args(0).is_function()` would evaluate to false in the case where it fails.


didn't try to check the value of '.is_function()', but I think this isn't the source of the problem. With the callback example the following code fails:

function antest()
        b = 2;

        af = (@(a)(dot(a,b)));

        callback(af,3)
endfunction

Instead this one works:

function antest()
        b = 2;

        af = (@(a)(dot(a,2)));

        callback(af,3)
endfunction

In both case an anonymous function is used, so '.is_function()' should always return the same value. For some reason the context with the b variables get lost in the feval call when a function is passed.

What's weird is that, if I understand the Octave code correctly, the feval accepting an octave_value just check that the supplied argument contains a function and then calls the feval accepting a function using the same '.function_value()' which fails when called directly in my example. I'm even considering a MinGW bug at this point.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Wed 17 Mar 2021 05:14:12 PM UTC, comment #6: 

Nice detective work!

If I read the current code correctly, `feval` should be called with the octave_value if it is not clear if the argument is an (inline) function or a function handle.
I'd guess that `args(0).is_function()` would evaluate to false in the case where it fails. It's possible that in previous versions the argument was an inline function while it is a function handle now.

This is probably something that should be fixed in NLOpt rather than in Octave. But I'll leave this report open in case someone with a better insight has a different opinion.

Wrt preparing a changeset for NLOpt: Afaict, ever since `feval` is a member function of the interpreter, it also has an overload for an octave_value argument.
Fwiw, an overload of `octave::feval` with an octave_value argument was introduced in this changeset:
https://hg.savannah.gnu.org/hgweb/octave/rev/55916f99b8b6
I believe this was for Octave 5.

I hope that helps.

Markus Mützel <mmuetzel>
Project Member
Tue 16 Mar 2021 11:11:42 AM UTC, comment #5: 

Hello,

I think I nailed down the problem. I started from the textbook example at:

https://octave.org/doc/v6.2.0/Calling-Octave-Functions-from-Oct_002dFiles.html#Calling-Octave-Functions-from-Oct_002dFiles

and compared it to the NLOpt Octave interface. In the end it all boils down to the following situation:

#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;

        // Works
        retval = interp.feval (args(0), newargs, nargout);

        // Fails
        retval = interp.feval (args(0).function_value(), newargs, nargout);

        return retval;
}

This trivial callback function has to be called passing an anonymous function with context inherited parameters like in the antest() example to see the problem happening.

The NLOpt interface uses some more convoluted code which is equivalent to the failing one above. I don't know if there has been some API change which forbids the second type of call in 6.X. If this is the case I'll fix the NLOpt interface and warn back the NLOpt developers.

Let me know.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Tue 16 Mar 2021 09:26:21 AM UTC, comment #4: 

Hello,

tried with 6.2.1, same behaviour. I took the time to reduce my code to something self contained, taking the rosenbrock function from the optim package:

function antest()
        # NLOPT Based

        ol = 1e-6;
        p = 5;

        # Initializes the optimization structure
        op = struct();

        # Set the algorithm to SQP
        op.algorithm = NLOPT_LD_SLSQP;

        # Set the objective function
        # op.min_objective = @rosenbrock; # <-- Works both with 5.2.0 and 6.2.X
        # op.min_objective = (@(t)(rosenbrock(t))); # <-- Works both with 5.2.0 and 6.2.X
        op.min_objective = (@(t)(rosenbrock(t,p))); # <-- Works with 5.2.0, doesn't work with 6.2.X

        # Set the tolerances for the optimization
        op.ftol_rel = ol;
        op.xtol_rel = ol;

        # Optimize
        sl = zeros(p,1);
        [ pl, se ] = nlopt_optimize(op,sl)
endfunction

function [obj_value, gradient] = rosenbrock(x,p = 0);
        x = x(:);
        dimension = length(x);
        obj_value = sum(100*(x(2:dimension)-x(1:dimension-1).^2).^2 + (1-x(1:dimension-1)).^2);
        if nargout > 1
                gradient = zeros(dimension, 1);
                gradient(1:dimension-1) = - 400*x(1:dimension-1).*(x(2:dimension)-x(1:dimension-1).^2) - 2*(1-x(1:dimension-1));
                gradient(2:dimension) = gradient(2:dimension) + 200*(x(2:dimension)-x(1:dimension-1).^2);
        endif
endfunction

I hadded a fake unused variable p to rosenbrock just to trigger the error. When it fails, both on 6.2.0 and 6.2.1 it gives again:

octave:33> antest
error: 'p' undefined near line 16, column 16
error: called from
    antest>@<anonymous> at line 16 column 27
    antest at line 24 column 13

Now that I know that at least it isn't a problem of my own code I'll dig also into che NLOpt Octave interface to see if there's something weird and see if I can trigger the problem with some reduced self contained example not involving the whoole NLOpt library.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Tue 16 Mar 2021 08:24:49 AM UTC, comment #3: 

Hello Dmitri ans Markus,

thanks for your reply.

comment #1:

> The code does not appear to be complete.
> What are: ol, p, sl?


Of course it isn't, the whole code is thousands of lines. The variables are of course all defined, else it wouldn't work with 5.2.0 or the optim package either. Some explanation:

nl, cl, gl: all double column vectors of the same size. Size of these depends on the problem size and goes from few to thousands. Tested with different sizes with the same result.

p, f, mm, ol: all double scalars.

I have to add that all the code has been thoroughly tested under 5.2.0 and previous versions going back to 4, solving reliably tens of thousands of similar problems of varying size. All the code, except for the optimization routine, is pure Octave code. No other external library is involved.

> If I fake those the code finishes w/o error that you see
> on a recent octave 6.2.1 (6.3 pre-release).
> You can try a recent windows builds from
> https://buildbot.octave.space/#/download


I'll try ASAP and let you know.

Thanks again.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>
Mon 15 Mar 2021 05:30:45 PM UTC, comment #2: 

What is `nl` and where is it defined? I cannot find it in your code snippet.

Markus Mützel <mmuetzel>
Project Member
Mon 15 Mar 2021 05:19:18 PM UTC, comment #1: 

The code does not appear to be complete.
What are: ol, p, sl?

If I fake those the code finishes w/o error that you see
on a recent octave 6.2.1 (6.3 pre-release).
You can try a recent windows builds from
https://buildbot.octave.space/#/download

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 15 Mar 2021 04:33:16 PM UTC, original submission:  

Hello,

I'm working with the NLopt optimization library (https://nlopt.readthedocs.io) and I get a different behaviour going from 5.2.0 to 6.2.0. First of all, NLOpt has been compiled outside of Octave using mingw64, so the NLopt binary library used for both cases is the same.

Under 5.2.0 the following code works:

# NLOPT Based

# Initializes the optimization structure
op = struct();

# Set the algorithm to SQP
op.algorithm = NLOPT_LD_SLSQP;

# Set the objective function
op.min_objective = (@(t)(qestnlopt(t(:),nl,p,f,cl,gl,mm,0.5 * ol)));

# Set the tolerances for the optimization
op.ftol_rel = ol;
op.xtol_rel = ol;

# Set the lower and upper bound
op.lower_bounds = zeros(p,1);
op.upper_bounds = ones(p,1);

# Gradient of the equality constraint
eg = ones(p,1);

# Set the equality constraints function
op.h = { @(t)(qestnlopteq(t,sl' * ones(p,1),eg)) };

# Set the tolerances for the equality constraints
op.h_tol = ol;

# Set the sorting inequality constraints function
op.fc = cell(p - 1,1);
for (r = (1:(p - 1)))
        op.fc(r) = (@(t)(qestnloptne(t,r,p)));
endfor

# Set the tolerances for the sorting inequality constraints
op.fc_tol = repmat(ol,p - 1,1);

# Optimize
[ pl, se ] = nlopt_optimize(op,sl);

Under 6.2.0 I get the following error:

error: 'nl' undefined near line 173, column 173
error: called from
    nlscov>@<anonymous> at line 173 column 29
    nlscov at line 202 column 15

It looks like Octave no longer sees the variables passed from context to the anonymous functions. At first I thought it was a NLopt bug but then I changed the code above to the following one:

# NLOPT Based

# Initializes the optimization structure
op = struct();

# Set the algorithm to SQP
op.algorithm = NLOPT_LD_SLSQP;

function [ r, v ] = lobjf(t)
        if (isargout(2) == true)
                [ r, v ] = qestnlopt(t(:),nl,p,f,cl,gl,mm,0.5 * ol);
        else
                r = qestnlopt(t(:),nl,p,f,cl,gl,mm,0.5 * ol);
        endif
endfunction

# Set the objective function
# op.min_objective = (@(t)(qestnlopt(t(:),nl,p,f,cl,gl,mm,0.5 * ol))); <-- CHANGED
op.min_objective = @lobjf;

# Set the tolerances for the optimization
op.ftol_rel = ol;
op.xtol_rel = ol;

# Set the lower and upper bound
op.lower_bounds = zeros(p,1);
op.upper_bounds = ones(p,1);

# Gradient of the equality constraint
eg = ones(p,1);

# Set the equality constraints function
# op.h = { @(t)(qestnlopteq(t,sl' * ones(p,1),eg)) }; <-- CHANGED
op.h = { str2func([ '@(t)(qestnlopteq(t,' num2str(sl' * ones(p,1)) ',ones(' num2str(p) ',1)))' ]) };

# Set the tolerances for the equality constraints
op.h_tol = ol;

# Set the sorting inequality constraints function
op.fc = cell(p - 1,1);
for (r = (1:(p - 1)))
        # op.fc(r) = (@(t)(qestnloptne(t,r,p))); <-- CHANGED
        op.fc(r) = str2func([ '@(t)(qestnloptne(t,' num2str(r) ',' num2str(p) '))' ]);
endfor

# Set the tolerances for the sorting inequality constraints
op.fc_tol = repmat(ol,p - 1,1);

# Optimize
[ pl, se ] = nlopt_optimize(op,sl);

With these changes it works also under 6.2.0 (and no longer works under 5.2.0 beacause handles to nested functions aren't supported, but this is expected). AFAIK if it was an NLopt bug it shouldn't work either in the second case. I know also that some changes to anonymous functions handling hsa been introduced since version 6, see for example bug #59989.

On the other hand, optimizing using the optim package, which also requires a similar approach with anonymous functions and some function parameters passed from context, works without problems both in 5.2.0 and 6.2.0, which is the reason why I initially thought it was an NLopt bug.

I tried to reproduce the error with some simpler code, hopefully not involving external libraries, to no avail. If someone might provide some hint I might try harder.

Hope it helps.

Bye,

Denis Sbragion

Denis Sbragion <dsbragion>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51188:  bug60237.m added by None (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by dsbragion (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-04-05 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2021-04-04 None Attached File- => Added bug60237.m, #51188
    2021-04-02 jwe StatusFixed => Ready For Test
        Open/ClosedClosed => Open
    2021-04-02 mmuetzel StatusReady For Test => Fixed
        Open/ClosedOpen => Closed
    2021-04-01 jwe StatusIn Progress => Ready For Test
    2021-03-17 mmuetzel StatusNeed Info => In Progress
        Operating SystemMicrosoft Windows => Any
    2021-03-15 mmuetzel StatusNone => Need Info

    Back to the top


    Powered by Savane 3.7