Bug regarding precedence of variables over functions sharing the same name?
4 次查看(过去 30 天)
显示 更早的评论
Let's say I have defined a variable called size (I'm just using "size" for the sake of a very simple example). MATLAB correctly goes to my variable instead of the standard function "size" when I type size. However, if I define my variable size in a script, then call that script from a function (such that the variable should exist in the function workspace), then try to reference the variable in the function, MATLAB tries to call the standard size function. Try this simple example. Make a script called yay.m that contains the following single line:
size=2;
Then make a function called doit.m that calls yay and then tries to access the variable size that yay has made:
function doit
yay
size
It will try to access the size function instead. You can even put a "which size" statement right after the call to yay and it will confirm "size is a variable.", but will still proceed to miss it and try to call the function size instead. What's going on??? Is this a bug in MATLAB?
0 个评论
回答(3 个)
Paulo Silva
2011-7-1
I don't see a bug, in scripts your variables are in the same scope has the command line but inside functions like your doit function the scope is just that doit function.
size in yay is a variable, yay is a script
size in doit is a MATLAB function, doit is a function
Ok I must admit that something weird is going on after testing and reading the documentation, matlab seems to be confused about it, when we ask what's size MATLAB says it's a variable but when using size to do something it's the MATLAB function again, MATLAB functions seem to take priority.
Try this:
global catch %in the first line of your yay script
global catch %in the second line of your doit function
Now catch is equal to 2 inside the function doit
Don't use variables with the same name as scripts or MATLAB functions, if you do use the same names you might get weird problems like the one you found.
4 个评论
Matt Fig
2011-7-1
True Paulo, that's why I said it isn't a bad bug ;-). But when the software behaves contrary to the documentation, it is a bug nonetheless.
Matt Fig
2011-7-1
I would call it a bug. All variables created in a script should exist inside the workspace from which the script was invoked. The workspace the script YAY was invoked from is the workspace of the DOIT function.
I used this:
function [] = doit()
% Calls script yay
yay
whos
try
size^2
catch
end
try
pi^2
catch
end
try
ismember^2
catch
end
try
A^2
catch
end
where the script yay.m is given by:
size = 2;
A = 6;
pi = 4;
ismember = 9;
Correction. The assignment fails even for ISMEMBER. What is funny is that I get a red M-Lint warning on the call to ISMEMBER but not on the call to SIZE.
Of course any bug that prevents the user from choosing such poor variable names is not a bad bug!
1 个评论
James Tursa
2011-7-1
Likely one of these parser quirks again. doit gets parsed and at that time it doesn't see any variable called size in the function so it thinks it is the built-in function size. When doit subsequently gets called it is this pre-parsed code that actually runs, so when a variable called size suddenly appears in the workspace as a result of the yay call it doesn't matter, the downstream reference to size has already been linked by the parser to the built-in function size. I seem to recall similar quirky behaviour with the parser when a function was called (not a script) and it put a variable directly in the caller workspace.
Walter Roberson
2011-7-11
This is not considered a bug: it is a consequence of the JIT. The documented (somewhere) work-around to it is to initialize the variable before invoking the script file.
If using script files to set variable names to override functions is important to you, then use feature() to turn 'accel' 'off'.
0 个评论
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Loops and Conditional Statements 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!