I'm having issues with the index for my code. I'm trying to create a code on Octave for the power method (vector iteration) and the error: 'x(4): out of bound 3' keeps popping up at line 6.
A=[6,-2,2,4;0,-4,2,2;0,0,2,-5;0,0,0,-3]
b=[12;10;-9;-3]
n=4
for i=rows(A):-1:1
for j=i+1:rows(A)
x(i)=[b(i)-A(i,j)*x(j)]/A(i,i); #error: 'x(4): out of bound 3'
endfor
endfor
x
In the following line, note that you have x appearing twice; the first seeks to assign to it, but the second simply tries to access its value:
x(i) = [ b(i) - A(i,j) * x(j) ] / A(i,i);
⬑ assignment ⬑ access
Assigning to an index that doesn't exist (yet) is absolutely fine; octave will simply fill in the intervening values with 'zeroes'. E.g.
>> clear x
>> x(3) = 1 % output: x = [0, 0, 1]
However, trying to access an index which doesn't exist yet is an error, since there's nothing there to access. This results in an "out of bound" error (and, in its error message, octave is kind enough to tell you what the last legitimate index is that you can access in that particular array).
Therefore, this is an error:
>> clear x
>> x(3) = 1 % output: x = [0, 0, 1]
>> 1 + x(4) % output: error: x(4): out of bound 3
Now going back to your specific code, you are trying to access something that doesn't exist yet. The reason it doesn't exist yet, is that you have set up your for loops such that j will achieve a higher value than i at a particular step, such that you are trying to access x(j), which does not exist yet, in order to assign it to x(i), where i < j. Therefore this results in an out of bounds error (you are trying to access index j when you only have up to i available).
In your particular case, octave informs you that this happened when j was 4, and i was 3.
PS: I will echo #HansHirse's implied warning here, that you should always pay attention to your variables, and clear them appropriately in your scripts, especially if you plan to run it many times. Never use a variable that you haven't defined (or cleared) beforehand. Otherwise, x here may not be undefined when you run your script, say, a second time. This leads to all sorts of problems, e.g., your code works but for the wrong reasons, and then fails to work again when you run it the next day and x is now undefined. In this particular example, if you had an x in your workspace which had the right number of elements in it, your code would "work" but produce the wrong result, and you wouldn't know any better.
Related
I'm trying to solve the following ODE:
where R(T) is defined as:
This is my not so great attempt at using Octave:
1;
function xdot = f(t, T)
xdot = 987 * ( 0.0000696 * ( 1 + 0.0038 * ( T(t) - 25 ))) - ( 0.0168 * (T(t)-25 )) - (( 3.25 * 10 ^ (-13))) * ((T(t))^4 - (25^4));
endfunction
[x, istate, msg] = lsode( "f", 100, (t=linspace(0,3600,1000)'));
T_ref and T_infinity_sign are the same constant.
Why isn't my code correct?
If you type
debug_on_error(1)
on your octave session, and then run your code, you will see that the "f" part is called as expected, but then it fails inside lsode with the following error:
error: T(100): out of bound 1 (dimensions are 1x1)
error: called from
f at line 4 column 8
If you look at the documentation of lsode, it says it expects a function f whose first argument is a state vector x, and the second is a scalar, corresponding to time t at which that state vector occurs; f is expected to output the differential dx/dt at time t for state vector x.
From your code it seems that you are reversing the order of the arguments (and their meanings).
Therefore, when you passed T as a second argument to your function, lsode treats it like a scalar, so when you then try to evaluate T(t), it fails with an 'out_of_bounds_ error.
My advice would be, read the documentation of lsode and have a look at its examples carefully, and start playing with it to understand how it works.
PS. The debug_on_error directive launches the debugger if an error occurs during code execution. To exit the debugger type dbquit (or if you're using the GUI, click on the 'Quit Debugging Mode' button at the top right of the octave editor). If you don't know how to use the octave debugger, I recommend you spend some time to learn it, it is a very useful tool.
I constructed several glmer.nb models with different combinations of random intercepts, and for one of the models (nested random intercepts, with the lowest AICc), I consistently get: "iteration limit reached", without the usual "Warning message:
In theta.ml(Y, mu, weights = object#resp$weights, limit = limit, :..."
Here's what I know:
it is a warning (from the color) but not labeled as such
you can also have that warning with GLMs and LMERs
Here's what I don't know:
does it mean the model is invalid?
what causes that issue?
what could I do to resolve that issue?
Here's what I searched:
https://stats.stackexchange.com/questions/67287/very-large-theta-values-using-glm-nb-in-r-alternative-approaches (no explanation as to the why and how)
GLMM FAQ: no mention
I am not the only regularly running into that or similar problems: Using glmer.nb(), the error message:(maxstephalfit) PIRLS step-halvings failed to reduce deviance in pwrssUpdate is returned
https://stats.stackexchange.com/questions/40647/lme-error-iteration-limit-reached/40664
Here's what would be highly appreciated:
A more informative warning message: did the model converge? what caused this? What can one do to fix it? Can we read more about this (link to GLMM FAQ - brms-style)?
This is a general question. I did not provide reproducible code because an answer that is generalisable would be most useful.
library(lme4)
dd <- data.frame(f = factor(rep(1:20, each = 20)))
dd$y <- simulate(~ 1 + (1|f), family = "poisson",
newdata = dd,
newparam = list(beta = 1, theta = 1),
seed = 101)[[1]]
m1 <- glmer.nb(y ~ 1 + (1|f), data = dd)
Warning message:
In theta.ml(Y, mu, weights = object#resp$weights, limit = limit, :
iteration limit reached
It's a bit hard to tell, but this warning occurs in MASS::theta.ml(), which is called to get an initial estimate of the dispersion parameter. (If you set options(error = recover, warn = 2), warnings will be converted to errors and errors will dump you into a debugger, where you can see the sequence of calls that were active when the warning/error occurred).
This generally occurs when the data (specifically, the conditional distribution of the data) is actually equidispersed (variance == mean) or underdispersed (i.e. variance < mean), which can't be achieved by a negative binomial distribution. If you run getME(m1, "glmer.nb.theta") you'll generally get a very large value (in this case it's 62376), which indicates where the optimizer gave up while it was trying to send the dispersion parameter to infinity.
You can:
ignore the warning (the negative binomial isn't a good choice, but the model is effectively converging to a Poisson solution anyway).
revert to a Poisson model (the CV question you link to does say "a Poisson model might be a better choice")
People often worry less about underdispersion than overdispersion (because underdispersion makes results of a Poisson model conservative), but if you want to take underdispersion into account you can fit your model with a conditional distribution that allows underdispersion as well as overdispersion (not directly possible within lme4, but see here)
PS the "iteration limit reached without convergence" warning in one of your linked answers, from nlminb within lme, is a completely different issue (except that both situations involve some form of iterative solution scheme with a set maximum number of iterations ...)
I generated random values using following function :
P = floor(6*rand(1,30)+1)
Then, using T=find(P==5), I got values where outcome is 5 and stored them in T. The output was :
T =
10 11 13 14 15 29
Now, I want to calculate the mean value of T using mean(T) but it gives me following error :
error: mean(29): out of bound 1 (dimensions are 1x1) (note: variable 'mean' shadows function)
What I am trying to do is to model the outcomes of a rolling a fair dice and counting the first time I get a 5 in outcomes. Then I want to take mean value of all those times.
Although you don't explicitly say so in your question, it looks like you wrote
mean = mean(T);
When I tried that, it worked the first time I ran the code but the second and subsequent times it gave the same error that you got. What seems to be happening is that the first time you run the script it calculates the mean of T, which is a scalar, i.e. it has dimensions 1x1, and then stores it in a variable called mean, which then also has dimensions 1x1. The second time you run it, the variable mean is still present in the environment so instead of calling the function mean() Octave tries to index the variable called mean using the vector T as the indices. The variable mean only has one element, whose index is 1, so the first element of T whose value is different from 1 is out of bounds. If you call your variable something other than mean, such as, say, mu:
mu = mean(T);
then it should work as intended. A less satisfactory solution would be to write clear all at the top of your script, so that the variable mean is only created after the function mean() has been called.
I am not sure what is the use of output while using fminunc.
>>options = optimset('GradObj','on','MaxIter','1');
>>initialTheta=zeros(2,1);
>>[optTheta, functionVal, exitFlag, output, grad, hessian]=
fminunc(#CostFunc,initialTheta,options);
>> output
output =
scalar structure containing the fields:
iterations = 11
successful = 10
funcCount = 21
Even when I use max no of iteration = 1 still it is giving no of iteration = 11??
Could anyone please explain me why is this happening?
help me with grad and hessian properties too, means the use of those.
Given we don't have the full code, I think the easiest thing for you to do to understand exactly what is happening is to just set a breakpoint in fminunc.m itself, and follow the logic of the code. This is one of the nice things about working with Octave, since the source code is provided and you can check it freely (there's often useful information in octave source code in fact, such as references to papers which they relied on for the implementation, etc).
From a quick look, it doesn't seem like fminunc expects a maxiter of 1. Have a look at line 211:
211 while (niter < maxiter && nfev < maxfev && ! info)
Since niter is initialised just before (at line 176) with the value of 1, in theory this loop will never be entered if your maxiter is 1, which defeats the whole point of the optimization.
There are other interesting things happening in there too, e.g. the inner while loop starting at line 272:
272 while (! suc && niter <= maxiter && nfev < maxfev && ! info)
This uses "shortcut evaluation", to first check if the previous iteration was "unsuccessful", before checking if the number of iterations are less than "maxiter".
In other words, if the previous iteration was successful, you don't get to run the inner loop at all, and you never get to increment niter.
What flags an iteration as "successful" seems to be defined by the ratio of "actual vs predicted reduction", as per the following (non-consecutive) lines:
286 actred = (fval - fval1) / (abs (fval1) + abs (fval));
...
295 prered = -t/(abs (fval) + abs (fval + t));
296 ratio = actred / prered;
...
321 if (ratio >= 1e-4)
322 ## Successful iteration.
...
326 nsuciter += 1;
...
328 endif
329
330 niter += 1;
In other words, it seems like fminunc will respect your maxiters ignoring whether these have been "successful" or "unsuccessful", with the exception that it does not like to "end" the algorithm at a "successful" turn (since the success condition needs to be fulfilled first before the maxiters condition is checked).
Obviously this is an academic point, since you shouldn't even be entering this inner loop when you couldn't even make it past the outer loop in the first place.
I cannot really know exactly what is going on without knowing your specific code, but you should be able to follow easily if you run your code with a breakpoint at fminunc. The maths behind that implementation may be complex, but the code itself seems fairly simple and straightforward enough to follow.
Good luck!
When I run this piece of code:
dx = 4/(nx-1);
dy = 2/(ny-1);
phinew(2:ny-1,2:nx-1) = ((dy^2*(phiold(1:ny-2,2:nx-1)+phiold(3:ny,2:nx-1))+dx^2*(phiold(2:ny-1,1:nx-2)+phiold(2:ny-1,3:nx)))/(2*(dx^2+dy^2))-poissonf);
Within my code, the piece of code operates correctly, taking an input of an nx by ny matrix and outputting a nx by ny matrix. When I run the following code in the exact same position however:
phinew = Smoothing(phiold,poissonf,nx,ny)
Where the function "Smoothing" is defined as:
function [phinew,dx,dy] = Smoothing(phiold,poissonf,nx,ny)
dx = 4/(nx-1);
dy = 2/(ny-1);
phinew(2:ny-1,2:nx-1) = ((dy^2*(phiold(1:ny-2,2:nx-1)+phiold(3:ny,2:nx-1))+dx^2*(phiold(2:ny-1,1:nx-2)+phiold(2:ny-1,3:nx)))/(2*(dx^2+dy^2))-poissonf);
end
The function returns a nx-1 by ny-1 matrix for an nx by ny input.
I cannot wrap my head around why this is occurring at all. The output matrix is the exact same as it should be, except the last column and row are missing entirely. My code is iterative and so requires these to be of the same size, so I cannot move on until this issue is resolved.
Thank you for your time and your help. You people are life-savers.
When you run your code in the command window, phinew already exists. In your command window, do clear phinew before you pasting in those three lines, and you'll find that phinew is then nx-1 by ny-1, as you get from your function.
If you want to force your function to return nx by ny, put phinew = zeros(nx,ny); at the start of the function, or set the last column and row to whatever you want them to be.
EDIT: Responding you your comment "why [does the RHS of the main assignment output] a 48x48 matrix? Directly before the command is run phiold, phinew and poissonf are all 50x50."
I don't think poissonf is 50x50: that would lead to the error Matrix dimensions must agree, because poissonf is being added to the rest of the expression which is part of phiold, so I'll ignore poissonf in the following.
The RHS is always ny-2 by nx-2, even on the first iteration. You can see this by assigning the RHS to an intermediate variable, e.g. phipiece = ... and checking size(phipiece). The reason phinew (if created anew) is 49x49 is because it is assigned to (2:ny-1,2:nx-1), which will create a ny-1 by nx-1 matrix and leave the first row and column as zero.
If you use phinew = zeros(nx,ny); first, then the first and last rows and columns are left as zero.