Bug regarding precedence of variables over functions sharing the same name?

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?

Answer 1

[Paulo Silva]

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.

[Matt Fig]

I would say it is a bug because the behaivior is inconsistent with the documentation. All variables created in a script should appear in the caller's workspace.

This holds when a script is called by a function as I show below.

The exception is for MATLAB functions and user defined functions, as I found out. I don't think it is a bad bug, BTW.

[Paulo Silva]

I agree with the inconsistency with the documentation but the situation that Giles found only happens when the user makes the mistake of using variables with the same name as functions and calls a script from a function, maybe he was the first person to do that with MATLAB.

[Matt Fig]

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.

[Paulo Silva]

please submit the bug to Mathworks so they can "kill it" :)

Answer 2

[Matt Fig]

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!

[James Tursa]

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.

Answer 3

[Walter Roberson]

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'.