Size of matrix changing when input through function

Something odd is occurring when I input a matrix through a function. I have the following in a script:
range = [500,2000];
increment = 100;
duty = range(1):increment:range(2);
It gets passed into the following function:
ODE_output = get_ODE(duty);
and the length of 'duty' within the get_ODE function goes from 16 to 186 columns. Instead of keeping the original matrix it creates a new one with the following size:
duty = 150:10:2000
I know at one point I had changed my conditions to the above, however I do not understand why it keeps reverting to that specific duty matrix.
I've cleared variables and restarted MATLAB numerous times. I've debugged this for a while and the duty matrix isn't called again until the get_ODE function.
Any ideas on why it's happening and how to fix this?
Thanks!

7 commentaires

Well, what is the code of get_ODE?
Note that whatever happens in the function get_ODE does not affect the values of the variables in your base workspace (except ODE_Output of course), even if they have the same name.
Duty is called two times within the ODE_output function. The following lines:
function ODE_output = get_ODE(duty)
mSize = length(duty);
for i = 1:mSize
force(i) = -g*duty(i);
end
end
Note this is an extremely abbreviated version of the code. The rest of it has no impact on duty. So the length of mSize ends up being 186, and if I print the duty at any point in get_ODE (first line, last line), I get a 1 x 186 matrix.
I'd suggest you post your code. If not the entire code, at least post a large enough segment that we can run it and reproduce the problem. It's hard to debug "weird" things like this without seeing the whole code.
When your duty is called by get_ODE, the value of duty will not be changed in your base workspace even if the size of duty changes inside your function. Are you sure, you are missing a part in your script where you mistakenly change your duty variable?
I second the suggestion to post code that displays the problem. I recommend trying to distill the code down to the bare minimum that exhibits the behavior. (Often, that process itself will expose the issue.)
Thank everyone. I actually figured it out. In my get_ODE function I was calling on a .mat file, however when I initially created the .mat it saved the entire workspace instead of the variables I wanted. This explains why it was reverting to previous workspace variables.
and that is why you never use plain load. Instead you assign it to a variable and assign the file content as fields of that variable. That way, you never run the risk that load is going to overwrite any of your current variables.

Connectez-vous pour commenter.

Réponses (0)

Catégories

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by