![]() ![]() > The code does not appear to be complete. 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. When it fails, both on 6.2.0 and 6.2.1 it gives again:Įrror: 'p' undefined near line 16, column 16 I hadded a fake unused variable p to rosenbrock just to trigger the error. I took the time to reduce my code to something self contained, taking the rosenbrock function from the optim package: If this is the case I'll fix the NLOpt interface and warn back the NLOpt developers. I don't know if there has been some API change which forbids the second type of call in 6.X. The NLOpt interface uses some more convoluted code which is equivalent to the failing one above. 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. Retval = interp.feval (args(0).function_value(), newargs, nargout) Retval = interp.feval (args(0), newargs, nargout) In the end it all boils down to the following situation: I started from the textbook example at:Īnd compared it to the NLOpt Octave interface. 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.įwiw, an overload of `octave::feval` with an octave_value argument was introduced in this changeset: But I'll leave this report open in case someone with a better insight has a different opinion. This is probably something that should be fixed in NLOpt rather than in Octave. It's possible that in previous versions the argument was an inline function while it is a function handle now. I'd guess that `args(0).is_function()` would evaluate to false in the case where it fails. 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'm even considering a MinGW bug at this point. ![]() 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. For some reason the context with the b variables get lost in the feval call when a function is passed. With the callback example the following code fails:Īf = both case an anonymous function is used, so '.is_function()' should always return the same value. > I'd guess that `args(0).is_function()` would evaluate to false in the case where it fails.ĭidn't try to check the value of '.is_function()', but I think this isn't the source of the problem. ![]() I changed the callback oct file to the following one:ĭEFMETHOD_DLD (callback, interp, args, nargout, "Callback Demo") Some further investigations, which, to tell the truth, didn't make the situation completely clear to me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |