Mystery Error; same code runs fine the 2nd time, but not the 1st!

The 1st run produces this error: "Unable to perform assignment because the left and right sides have a different number of elements." The same exact identical code, works fine the 2nd time around. What gives? Installation issues? Cache problems?

MATLAB Version: 9.6.0.1099231 (R2019a) Update 1

[Guillaume]

Bug in your code. You're reusing an existing variable without setting its size correctly beforehand.

We can't tell you more without seeing said code.

[Star Strider]

Update 3 is now available.

[Sree]

My codes are attached. If you save them all in a folder and run the main code, you'll see the problem. Thanks.

[Jan]

It would be useful, if you post the error message. I guess "the main code" is "Euler_Main_All.m".

Answer 1

[Jan]

Without seeing the relevant part of the code, answering is based on guessing.

I guess, that your code is a script and not a function. Inside the script some variables are defined at the first run such that the second run can use them.

Neither "installation issues" nor "cache problems" are standing to reason. Most likely this is a simple programming error. You can use the debugger to test this. Another approach is to convert the script into a function, and check, if the problem occurs every time. Then you know that the data shared with previous runs is the source of the different behaviour.

[Sree]

Thanks. I have attached my codes in reply to another responder. Let me know if you cannot access the codes.

[Jan]

The code is hard to debug. The brute clearing header clc, clear, close all is a waste of time. Global variables are an ugly way to impede debugging. Inputs defined manually by input() are bad also, because it is hard to reproduce a result. I cannot run your code, because I do not know, what you fill in in the input commands.

My suggestion:

• Convert the script "Euler_Main_All.m" to a function
• Omit the brute clearing header, because it is not useful here (see "Cargo-Cult-Programming")
• Do not use global variables
• Define the inputs as code, not dynamically by input. Then it is easy to reproduce a result and to let e.g. the users in the forum runm exactly the same as you do.

I bet with these clean programming style the actual problem will vanish.

[Dennis]

You would win that bet!

But I learned something new today! Even with the nuke from orbit approach (clc, clear, close all) you do not get rid of global variables.

The error in the code is that lambda is used before it actually has a value (Euler_Main_All). However when the code is executed a second time the script can access the value of lambda from the first run (do not use global variables!).

[Sree]

Thanks. (Dennis nailed it.) The code works now, after removing global variables, and defining lambda properly. Inputs are still retained; quite useful when you are asking others to run your code (without their having to edit the code); their inputs will be logged in the diary file. (Had I sent you my diary file along with the codes, debugging would've been easier.) "Nuke" clear/clc/ close commands are kept as well for similar reasons. "Cargo cult programming?" Hmm! Thanks just the same.

P.S. That "global variable" habit is vestigial, from decades of Fortran coding. But I get it; don't use them in Matlab.