Shiver. Obscene code. Not a single comment. Variables that have no apparent meaning to anyone, even the author. All to compute something where we are given no clue as to the purpose. Using the letter o as a variable name is a bad idea too, as it is too easily confused with the number 0 in some fonts. This will one day cause bugs for you, when you type 0 meaning o, or vice versa.
You do not pay extra per character. Variables with actual mnemonic names are not less efficient to use. But they do allow you to read the code more easily. This helps you to debug the code. Comments help you to debug the code.
Learn to use indentation constructively. This helps you to visualize loops and if statements.
Next, learn to use functions. They help to break the code into small fragments, each of which is then easy to debug. Test those functions separately. Verify every fragment does what you want it to do.
No, none of this helps you to solve your problem. At the same time, your problem is impossible to diagnose by someone else. We cannot read this mess of spaghetti code, nor can we know what it SHOULD be doing. If there is a bug (very possible) then how do we know where the bug came from?
For example, in the very beginning, you have a call to normrnd. In the help for normrnd, the second argument is a standard deviation.
a=normrnd(0,s^2,5000,1); % A probable error
Note that you are passing in the square of a variable here, a probable variance. You won't get what you expect to see. Is this your problem? Who knows? It is most likely just a bug in your code that will probably generate meaningless garbage for results. But how can I know? Perhaps you have defined the variable s as the sqrt of a standard deviation?
I did enjoy this code fragment:
format long g
out;
Of course, nothing will be displayed.
So I could continue to look through your code, trying to get inside your head. That would take god knows how long to do. So the only person who can debug this code is you. Learn to use tools like the debugger.
You should learn to write cleaner, readable, documented code. If it takes you a few minutes longer to write, who cares? It may well take you hours to debug this mess of code. For anyone else, that task would take far longer, even if they are given a clue as to what it should be doing.
This is a script. So learn to use scripting tools. Add comments. Learn to use the editor to run a section of your scripts, broken up by lines that start with the %% characters. Then you can run a small block of code, verify that it ran correctly. You can then fix any problems, and then re-run that block.
%%initialization of constants
s=4; % standard deviation of something for a simulation
z0=0.3;
index=7;index1=0;
o=40;
% what will a be used for? why 5000 elements?
a=normrnd(0,s^2,5000,1); % A probable error
phi=0.5;
% what is n?
n=[300;350;400;480;500;600;650;700;800;900;1000;1200;1300;1500;1700;1900;2000;2100;2300;2500;2700;2900;3000;3300;3500;3900;4200;4400;4600;4900;5300;5700;5900;6000;6600;6800;7000;7100;7300;7500;7900;8200;8500;8700;8900;9000;9200;9500;9700;1000];
%%What do these loops do?
for nn=1:o
z=[];
z(1)=phi*z0+a(1);
for i=2:n(nn)
z(i)=phi*z(i-1)+a(i);
end
for i=2:n(nn)
g(i)=z(i)*z(i-1);
end
...
There are LOTS of other problems I could point out. For example, growing the variable z dynamically is REALLY bad idea. It will create very slow running code. You know how big it will be in the end!!!!!!! So preallocate z to be the final size. Otherwise, you force MATLAB to reallocate more and more memory every time the array is grown, copying the entire array to new locations. So this operation takes quadratic time to process, growing slower and slower, quadratically with size of the array z.
