Sun 11 Oct 2015 11:22:13 PM UTC, comment #11:
Since the patch appears to avoid the reported problem, I'd say we could go ahead and push it. I updated it (needed because of the recent error_state changes) and pushed it here:
http://hg.savannah.gnu.org/hgweb/octave/rev/f9c991dc5c1a
|
Sun 11 Oct 2015 12:03:13 AM UTC, comment #10:
@jwe: Any reason why your patch can't be applied now?
|
Sat 29 Aug 2015 05:25:15 PM UTC, comment #9:
@jwe: Patch seems good. It resolves this issue and 'make check' passes. I appended to your changes a new file test/anonfunc.tst which has a few tests, including this one, for anonymous functions. I ran some benchmarking with 'make check' and there is a very slight slowdown with the new code, but it is close to the measurement resolution so can be ignored. Seems like this is fixed now.
(file #34768)
|
Sat 29 Aug 2015 01:59:06 PM UTC, comment #8:
Very deep in the weeds. I had no idea functions like _current_scope_ existed. I corrected the function name in the docstring and added a one-line definition here (http://hg.savannah.gnu.org/hgweb/octave/rev/33b03b06442b).
Attached is a little m-file mainfcn.m which shows how scope and context change with a function, subfunction, nested function and recursion--useful for learning.
Function is
Output is
(file #34765)
|
Sat 29 Aug 2015 01:57:36 PM UTC, comment #7:
The attached patch avoids the problem for me. I'm not yet sure if there is a better way than just avoiding the optimization for calls to eval/feval, or whether there are other cases that could cause trouble.
(file #34764)
|
Fri 28 Aug 2015 08:03:07 PM UTC, comment #6:
I meant
|
Fri 28 Aug 2015 08:02:18 PM UTC, comment #5:
I'm retitling this report.
Note the difference in the following:
The trouble is caused by this function:
http://hg.savannah.gnu.org/hgweb/octave/annotate/2f94652de9ff/libinterp/octave-value/ov-fcn-handle.cc#l1945
I believe the purpose of the octave_fcn_binder object is to optimize things like
so that they are almost as efficient as calling the internal function directly instead of going through all the effort of evaluating a user-defined function simply to call another function or simple expression.
You can show that the problem disappears if you make the body of the octave_fcn_binder::maybe_binder function be
I'm looking to see whether there is a simple fix that will preserve this optimization and make the eval case work properly.
|
Fri 28 Aug 2015 03:50:09 PM UTC, comment #4:
I don't think Matlab is looking at strings for additional variable names. For example, the following should produce 42 as a result, and at the time of parsing the anonymous function, there is no way to guess what string will be passed to the eval function:
So I think the issue is that when evaluating anonymous functions, the parameters to the anonymous functions are not considered. I haven't looked at this carefully, but my guess would be that the function parameters are in a separate scope but the body of the function is being evaluated in whatever scope it appears in, and that doesn't include the function parameters. The fix that is needed is probably just a small change in the way variables are looked up in this case so that the function parameters are also searched and found first.
|
Thu 27 Aug 2015 10:00:06 PM UTC, comment #3:
Thanks Mike. I re-titled the report to accurately reflect the issue. Octave does not look for anonymous variables within strings; It treats strings as atomic objects, while Matlab does do another round of parsing looking for variables within the string.
|
Thu 27 Aug 2015 09:46:13 PM UTC, comment #2:
In Matlab:
|
Thu 27 Aug 2015 09:17:39 PM UTC, comment #1:
Octave also waits to execute eval().
In this case, 't' is a string and is not subject to variable replacement in the anonymous function.
In your second case, t is not used as a string but as a variable.
One can verify that the eval is taking place because the return value of num2str is a char variable, but the return value of the anonymous function f is a double value which only happens because a string like "42" has been eval'ed.
If you have access to Matlab, what does it return for the following?
|
Thu 27 Aug 2015 02:23:43 PM UTC, original submission:
Calling
produces
So you could think the string is evaluated on the assignment of f. This is confirmed by the following:
Which returns 3.
But if you type following, you see that the statement above is not true:
which returns 42.
In Matlab, the string within eval is only evaluated when f is called, consistently.
|