Bug regarding precedence of variables over functions sharing the same name?
4 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
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 commentaires
Réponses (3)
Paulo Silva
le 1 Juil 2011
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 commentaires
Matt Fig
le 1 Juil 2011
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
le 1 Juil 2011
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 commentaire
James Tursa
le 1 Juil 2011
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
le 11 Juil 2011
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 commentaires
Voir également
Catégories
En savoir plus sur Loops and Conditional Statements dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!