Function call doesn't work in script, works in command window

I have a function that calls a sub-function within the same file: in main.m:

function main()
   ...
   [a,b,c,d,e,f,g,h]=TimeCalculations(x1,x2,x3,x4,x5,x6);
   ...
end

function [a,b,c,d,e,f,g,h]=TimeCalculations(x1,x2,x3,x4,x5,x6)
   ... %calculations for a,b,c,d,e,f,g,h
end

When I run main(), the program errors on the call to TimeCalculations(). The error output is: too many output arguments. However, when I put a breakpoint at this line and then copy the line directly into the command window, I do not receive and error. Has anyone run into a similar scenario and how did they fix it?

[OCDER]

function main()
    x1 = 1;
    x2 = 2;
    x3 = 3;
    x4 = 4;
    x5 = 5;
    x6 = 6;
   [a,b,c,d,e,f,g,h] = TimeCalculations(x1,x2,x3,x4,x5,x6);
end
function [a,b,c,d,e,f,g,h] = TimeCalculations(x1,x2,x3,x4,x5,x6)
   a = x1;
   b = x2;
   c = x3;
   d = x4;
   e = x5;
   f = x6;
   g = x1;
   h = x2;
end

I don't get any error... Maybe the error isn't here, but in the full code. Can you provide that?

[Steven Lord]

Please show the full text of the error message (everything in red) and show the rest of the code in your main() function.

Does your main() function contain a call to load?

Answer 1

[Matt J]

My only theory - you have another version of TimeCalculations which is not a sub-function. When you copy the call to the command window, it is that version which gets called. From the breakpoint, use the debugger controls to step into TimeCalculations() to see exactly where you are and what is getting computed.

[OCDER]

I also suspected this, but sub-function takes precedence over a private function which takes precedence over a local function elsewhere.

https://www.mathworks.com/help/matlab/matlab_prog/function-precedence-order.html

If the breakpoint is being used correctly, it should have called the subfunction TimeCalculations()... odd

[Matt J]

it should have called the subfunction TimeCalculations().

Maybe that's where the bug is. Maybe the shadowed version is the one that is working as it should.

Answer 2

[matthew]

I appreciate the feedback. We tracked down the problem. It's odd. In my psuedocode above, x5 is actually a variable called "info." It's a structure that is imported from another file. When calling TimeCalculations(....,info,...) in the script, Matlab must do something, I'm not sure what, but it doesn't pass the data structure "info" in. Instead, it calls the Matlab built-in function, info(). However, when I copy and paste the code into the command window, Matlab passes in the correct structure. Interestingly, I also couldn't assign the info structure to another variable and try to pass that in; that also resulted in an error. In the end, the only solution I found was to execute the code as follows:

eval('NewInfo=info');
clear info
[...]=TimeCalculations(....,NewInfo,...);

Now it works. Why I had to go this route, I don't understand. If anyone knows why Matlab evaluates the line differently depending on if it's in the m-file or the command window, I'd like to know.

THANKS!

[Walter Roberson]

"x5 is actually a variable called "info." It's a structure that is imported from another file."

How is it imported? If it is imported by way of a load() with no output argument, or by way of an evalin() or assignin(), then this is expected behavior.

In modern MATLAB, if you "poof" a variable into existence inside a function, then if there is a function with the same name as the variable being poofed, then MATLAB will use the function instead of the variable. The work-around is to assign to the variable before the code that poofs it into existence, or to not poof it into existence (e.g., assign the output of load() to a variable and extract the appropriate field from the variable.)

[OCDER]

Hm... The "Answer" is reinforcing bad coding habits that'll cause more trouble later. Just recount how long it took to debug this error, and no one in the forum could pinpoint the issue immediately because those are the hard bugs to find. Debugging the code requires a variable-by-variable analysis, which is painful...

The real issues are:

1. improper usage of eval or load (no idea if you have the right function/variable.)
2. poofing in variables (can't check if you have the variable you need, or variable will be overridden by mistake)
3. using clear (now you have to keep track of variables to clear/not clear. more bugs)
4. improper variable naming practice that likely overrides matlab built-in functions

To fix, start by:

1. Avoid eval, load, assignin, evalin, globals
2. Make sure every variable is clearly defined in the function
3. Avoid clear by having temporary variables defined in function/subfunction that auto clears them when function ends
4. Make all your variables start with a capital letter (until you know every function by heart... actually, just use caps on variable's 1st letter. easy fix.)

   Info = struct;
   which info  %matlab function 
   which Info  %your variable

[Stephen23]

"We tracked down the problem. It's odd."

Its not odd at all: the code is simply badly designed because variables magically appear in the workspace. The solution is simple: do NOT make variables magically appear in any workspace. This is a topic that has been discussed many many times before:

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

"In the end, the only solution I found was to execute the code as follows"

A much better solution would be to avoid eval and "poof"-ing variables into the workspace.