I am getting error in my Matlab code. I am using R2009b version
Frame index must be a numeric value greater than zero and less
than or equal to the number of frames in the file.
Error in ==> mmreader.read at 74
videoFrames = read(getImpl(obj), index);
Error in ==> testing at 10
Ii=read(mov,k*10);
Just a hunch, but I'm guessing that your frame index is not:
a numeric value greater than zero and less than or equal to the number
of frames in the file.
MATLAB is telling you that the error is happening in mmreader.read, and it is happening when you call mmreader.read at this point in your file testing:
Ii=read(mov,k*10);
If your movie reader object mov contains less than k*10 frames, or if k is zero or a negative number, you are asking MATLAB to do something impossible.
These sort of errors can be easily tracked down by typing dbstop if error at the command line, which means that when there is an error you enter debug mode. At this point you can then check what the value of k is, and also the number of available frames in mov.
Related
I read 16 Bit two's complement sensor data byte after byte via I2C with a STM32, so I have to stick the High- and Low-Byte back together and convert this number to a float to get the real value.
My expression in C for this is
// Convert temperature value (256 LSBs/°C with +25°C Offset)
float temp = (tmpData[1] << 8 | tmpData[0])/256.0 + 25.0;
When I use the debugger of the STM32CubeIDE to check the calculation, the expression shows the correct conversion of the data (see screenshot). But the value assigned to the temp variable is always 25! It seems to me like the first term of the expression is always assumed to be 0 or something? I already tried a direct cast of the term in brackets to float, but that does not change anything.
Can anybody point me to the problem? Why is the debugger showing the correct value, but the code is assigning a wrong one?
The expressions in the screenshots below are captured by howering the mouse over the corresponding part of the above code line in debug mode.
Fig. 1: Complete expression of calculation (gives result as expected)
Fig. 2: tmpData content (original two Bytes)
Fig. 3: Result of byte shifting and sticking
Fig. 4: temp result (always 25, even when expression above showes the expected value)
temp is only a volatile for the moment, because I don't use that value yet and the compiler optimizes it out.
many issues in this single line of code.
tmpData[1] << 8 has to be (((uint16_t)tmpData[1]) << 8). If you shift byte 8 times the result will be zero (standard says undefined). You probably got the warning about it.
256.0 & 25.0 are double values and the result will also be double then converted to the float. You shuold use 256.0f and 25.0f.
you can see the difference here: https://godbolt.org/z/Cm-S8T
OK, new morning, new intuition...
The problem wasn't with this code line from the question, but (typ. Murphy) with the stuff I did not post. The I2C is read via DMA to the array and at the point I wanted to do the conversion the peripheral was not done yet. That's why the array elements were always empty when the code accessed them, but at the time I checked the values in the debugger the I2C peripheral had finished the transmission and I saw the expected values.
So the solution is to check if the peripheral is still busy...
I am aware that dozens of threads have been started about this particular error, but none of them actually answer the problem I'm having.
I'm trying to generate a plot of voltage spikes at given intervals using the following code:
V=zeros(1:NN);
nspace=50; % Spacing of the spikes in angstroms
V0=-0.1*eV2J; % magnitude of the voltage spikes
for n=10/nspace:NN:nspace
V(nspace*n)=V0;
end
The variables NN and eV2J are already defined earlier in the code.
Now, here's the problem I'm having that the other threads don't answer. The indexing error only pops up for certain values of nspace, but not for others. For example, this block of code executes just fine for...
nspace = 20,23,24,27,29,31,32,33,34,36,37,38,40
...but the error occurs for all other integer values between 20 and 40, and this seemingly random distribution of acceptable values continues on past 40 as well. The index generated for all of these values are indeed integers (starting at 10 and incrementing by nspace each loop).
Every thread I've seen for this error states that is occurs when a variable sharaes a name with a built in MATLAB function, or when the index is not a positive real integer or logical. That is clearly not the case here.
Any ideas?
I have coded an algorithm in MATLAB which contains a loop. The code works well for a number of iterations, then suddenly stops due to the following error
??? Index exceeds matrix dimensions.
What could be the cause of this error?
This is part of the code.
[x,fval,exitflag,output]=cplexmilp(f,Aineq,bineq,Aeq,beq,sostype,sosind,soswt,lb,ub,ctype,x0,options)
for m=1:100
supply=[];
supply=x(1:p*w*t);
supply=reshape(supply,w,p*t)';
Failprob=[0.1927 0.1753 0.1728 0.1165 0.2375 0.1649];%Low
%Failprob=[0.3770 0.3061 0.2894 0.2682 0.3993 0.2983];%Med
Failprob=[0.5708 0.4842 0.4097 0.5144 0.4205 0.4312];%High
%Failprob=[0.4547 0.4958 0.4965 0.4158 0.4971 0.4957];%High
Epsilon=[.8 .9];%Low
%Epsilon=[.7 .9];%Med
Epsilon=[.6 .9];%High
Sigma=.05;%Low
%Sigma=.10;%Med
Sigma=.2;%High
Failprob=Failprob';
prob2=1-Failprob;
prob2=horzcat(prob2,Failprob);
prob2=repmat(prob2,t,1);
for n=1:t
for i=1+p*(n-1):p+p*(n-1)
for j=1:w
r=rand;
prob=prob2(i,:);
prob=cumsum(prob);
value=[supply(i,j),(Epsilon(1)+(Epsilon(2)-Epsilon(1))*rand(1))*supply(i,j)];
%values corresponding to the probabilities
ind=find(r<=prob,1,'first');
supply(i,j)=value(ind);
end
end
end
After some iterations, I have the following output.
Iteration 20 Current value 12020253.6911 Best value 12020253.6911
Iteration 21 Current value 10841341.9259 Best value 10841341.9259
Iteration 22 Current value 11307742.3543 Best value 10841341.9259
Iteration 23 Current value 10784746.9812 Best value 10784746.9812
??? Index exceeds matrix dimensions.
Error in ==> CodefinalTwelveGuMulti at 1947
supply=x(1:p*w*t);
I don't even know how that code could even run. x is not defined anywhere and you suddenly are starting to use it in your for loop at the beginning. My guess is that you have some code defined somewhere earlier on, those iterations start happening and then once those iterations end, this function runs. That makes sense since I don't see any print-out statements anywhere in your code.
That's what the error is alluding to. It is stating that you are trying to index into x with indices that exceed the dimensions of x. In this case, x has no dimensions (i.e. empty). As such, no matter what indices you are using to try to index into x, MATLAB will give you an index exceeding error.
You need to either define x by providing it as an input into your function, or define it inside the function itself.
I am working on a project that needs to use hidden markov models. I downloaded Kevin Murphy's toolbox. I have some problems about the usage. In the toolbox webpage, he says that first input of dhmm_em and dhmm_logprob are symbol sequence data. On their examples, they give row vectors as data. So, when I give my symbol sequence as row vector, I get error;
??? Error using ==> assert at 9
assertion violated:
Error in ==> fwdback at 105
assert(approxeq(sum(alpha(:,t)),1))
Error in ==> dhmm_logprob at 17
[alpha, beta, gamma, ll] = fwdback(prior,
transmat, obslik, 'fwd_only', 1);
Error in ==> mainCourseProject at 110
loglik(train_act) =
dhmm_logprob(orderedSymbols,
hmm{train_act}.prior,
hmm{train_act}.trans,
hmm{act}.emiss);
However, before giving this error, code works for some symbol vectors. When I give my data as column vector, functions work fine, no errors. So why exactly am I getting this error?
You might say that I should be giving not single vectors, but vector sets, I also tried to collect my feature vectors in a struct and give row vectors as such, but nothing changed, I still get assertion error.
By the way, my symbol sequence does not have any zeros, I am doing everything almost the same as they showed in their examples, so I would be greatful if anyone could help me please.
Im not sure, but from the function call stack shown above, shouldn't the last line be hmm{train_act}.emiss instead of hmm{act}.emiss.
In other words when you computing the log-probability of a sequence, you should pass components that belong to the same HMM model (transition matrix, emission matrix, and prior probabilities).
By the way, the ASSERT in the code is a sanity check that a vector of probabilities should sum to 1. Oftentimes, when working with very small values (log-probabilities), numerical stability issues can creep in... You could edit the APPROXEQ function to relax the comparison a bit, by giving it a bigger margin of error
This error message and the code it refers to are human-readable. An assertion is a guard put in by the programmer, to ensure that certain conditions are met. In this case, what is the condition? approxeq(sum(alpha(:,t)),1) I'd venture to say that approxeq wants the values to be approximately equal, so this boils down to: sum(alpha(:,t)) ~= 1
Without knowing anything about the code, I'd also guess that these refer to probabilities. The probabilities of a node's edges must sum to one. Hopefully this starts you down a productive debugging path. If you can't figure out what's wrong with your input that produces this condition, start wading into the code a bit to see where this alpha vector comes from, and how it ended up invalid.
HI
I wrote a program that use to work (swear to god) and has stopped from working. this code takes a series of BMPs and convert them into avi file. this is the code:
path4avi='C:/FadeOutMask/'; %dont forget the '/' in the end of the path
pathOfFrames='C:/FadeOutMask/';
NumberOfFiles=1;
NumberOfFrames=10;
%1:1:(NumberOfFiles)
for i=0:1:(NumberOfFiles-1)
FileName=strcat(path4avi,'FadeMaskAsael',int2str(i),'.avi') %the generated file
aviobj = avifile(FileName,'compression','None');
aviobj.fps=10;
for j=0:1:(NumberOfFrames-1)
Frame=strcat(pathOfFrames,'MaskFade',int2str(i*10+j),'.bmp') %not a good name for thedirectory
[Fa,map]=imread(Frame);
imshow(Fa,map);
F=getframe();
aviobj=addframe(aviobj,F)
end
aviobj=close(aviobj);
end
And this is the error I get:
??? Error using ==> checkDisplayRange at 22
HIGH must be greater than LOW.
Error in ==> imageDisplayValidateParams at 57
common_args.DisplayRange = checkDisplayRange(common_args.DisplayRange,mfilename);
Error in ==> imageDisplayParseInputs at 79
common_args = imageDisplayValidateParams(common_args);
Error in ==> imshow at 199
[common_args,specific_args] = ...
Error in ==> ConverterDosenWorkd at 19
imshow(Fa,map);
for some reason I cant put it as code segments. sorry
thank you
Ariel
Are the BMP images indexed? I think the map parameter only applies to images with indexed color maps.
The only way I am able to reproduce the error that you get is when map is a two-element vector where the first element is greater than the second. Note first that the function IMSHOW can be called with the following syntax:
imshow(I,[low high]);
In which I is a grayscale image and low and high specify the display range for the pixel intensities. The extra argument is ignored when I is an RGB image, but even then the value of high must be greater than the value of low or an error is thrown (the one you see above).
What's confusing is why map would be a two-element vector. When loading an image with IMREAD, the map output will either be empty (if the image is not an indexed image) or it will be an N-by-3 color map. I can't think of a situation where the built-in IMREAD would return a map argument with just 2 elements.
Based on the fact that you said it was working, and now suddenly isn't, I would suggest first checking to see if you have inadvertently created an m-file somewhere with the name imread. Doing so could cause that new imread function to be called instead of the built-in one, giving you different outputs than you expect.