Why doesn't MATLAB recognize the variable I have assigned in a script called from a function?

In a function, I call a script that assigns various variables, one of which (tf) happens to be the name of a predefined MATLAB function. When I then evaluate the variable in the function, it defaults as the MATLAB function name rather than the variable.

Is there a good reason for this? Is there an optimal solution, other than changing my variable name?

[Stephen23]

"Is there an optimal solution"

Yes: change the variable name.

I know you will then point out that you specifically asked for a solution other than this... but the reality is that this is the best solution. Naming every function/script/variable with its own unique name means that you will never face any uncertainty in what will be called, that any error message will unambiguously relate to that function/script/variable, that changing the MATLAB Search Path does not run the risk of changing your code's behavior, that you can distribute your code to others and know that it will work, that you make it clear in your code where that script/function/variable is called that you really mean my_special_tf and not just tf (which to any reasonable person using an internet search engine would mean an inbuilt MATLAB function)... oh, and of course it also means that you can still use the inbuilt function!

[Walter Roberson]

The problem is the variable name, not the script name.

Answer 1

[Walter Roberson]

Since R2015b, Mathworks has been getting stricter on the effects of assigning to a variable in a script and then using the variable in a function that invokes the script. Exactly what happens depends upon exactly which release you are using, but the current situation is this:

When current MATLAB parses a function, it looks at the names of all values that are clearly being assigned to in the function or passed into the function (or declared as global). If it sees a name that there is no obvious assignment to, then MATLAB will look on the search path to see if the name is the name of a known function. If it is the name of a known function, then MATLAB will assume that the reference is a call to the known function; if it is not the name of a known function, then it leaves it to be resolved at run-time.

If the function invokes a script that assigns to names, then if the name was not one of the known functions, then that assignment will provide the run-time resolution for the variable. However, if the name was the same as one of the known functions, then MATLAB will not change the name resolution in the function: the reference in the function will continue to be to the function.

There are three important work-arounds to this:

1. do not use scripts; Or;
2. do not use local variable names that are the same as the names of functions on the path; Or;
3. before invoking the script, assign something to the variable name so that MATLAB knows to treat it as a variable.

Examples:

function my_function1
   my_script;    %assigns to tf
   tf(1:3)      %MATLAB will assume this refers to tf function

function my_function2
  tf = [];   %assign anything to it
  my_script;  %assigns to tf
  tf(1:3)     %refers to variable

Note that the same issues can now occur if there are assignin() calls, and can also occur if you load() a file that has the variable in it:

function my_function3
  load abc   %suppose it contains variable tf
  tf(1:3)    %MATLAB will assume this refers to tf function

The important work-around for load is to always assign the result of load to a variable and access the variable:

function my_function4
   datastruct = load('abc.mat');
   datastruct.tf(1:3)   %access loaded variable directly
   tf = datastruct.tf;  %or extract it from the data structure
   tf(1:3)       %MATLAB can see the assignment to tf and so will not resolve to the function

Having variables "suddenly appear" without obvious assignment to them is often referred to as "poofing" the variable into existence. MATLAB is increasingly saying that if you do poof a variable into existence, then it might not pay attention.

[David Russell]

Thanks, great answer. I'm using the script as a list of parameters and options for the function, and I'm trying to avoid making it a function because of all the clutter caused by packing and unpacking the input/output structs. Pre-assigning each variable would be its own form of clutter, but as long as I know which ones to pre-assign, I guess it's not that much.

[Jan]

@David: Your problem shows another time, that at scripts cause more clutter. You might need some minutes with writing the code for packing the parameters into structs, it might cost some micro-seconds of runtime, but it can save you hours of debugging.

[David Russell]

@Jan: Actually, I am thinking more in debugging terms. In particular, I am trying to trim down the number of lines of code in the function file so I can read through it more easily. I'm getting the sense that perhaps it is frowned-upon to use scripts for this purpose, though. I suppose not unpacking the input struct is another option, as long as its name is short.

[Jan]

@David: If you code is working and efficient, it will be used and expanded sooner or later. While scripts might be efficient in terms of programming+debug time for a program with 5000 lines of code, the effort for debugging can explode for 100'000 lines of code. As soon as somebody else modifies your code, it is very useful to have all code encapsulated securely in functions to avoid any unwanted side-effects between variables used in scripts and their callers.

[Stephen23]

"I am thinking more in debugging terms. In particular, I am trying to trim down the number of lines of code in the function file so I can read through it more easily. I'm getting the sense that perhaps it is frowned-upon to use scripts for this purpose, though"

As code gets bigger and more complex, the advantages of functions become more and more important, in particular that their independent workspaces, and the ease of providing encapsulated functionality. An uncontrolled workspace containing all variables and operations for many different steps and algorithms is a recipe for bugs: functions are one way to avoid unintentional side-effects between different parts of the code. Testing and documenting a function is much simpler because it is encapsulated.

Being able to see the variables in the base workspace is certainly nice and is why some beginners prefer scripts, but as code gets more complex the more flexible and versatile debugging options (e.g. setting conditional breakpoints, stepping line by line, etc) actually make using the debugging tools properly more important and useful.

"I suppose not unpacking the input struct is another option, as long as its name is short."

Yes, that would likely be best choice to make. Packing and unpacking is a red herring, and serves no real purpose when the data can be accessed efficiently directly from the structure.