row index exceeds table dimensions?

I'm getting the error "row index exceeds table dimensions". Not sure how I'm getting this now because I use it earlier in my script and it works fine?

This is the code im using:

SF3 = SF2(MParam,:)

I use similar variations of this code a few times in the earlier lines but all of a sudden it gives me this error and I'm not even surer what it means, nevermind how to fix it.

[dpb]

The error is telling you that however you computed the value MParam, it's greater than the value of height(SF2), the number of rows in the table.

How to fix is to make sure that isn't so in whatever it is that creates the number...

[Ewan Compton]

Yes that makes sense. However, MParam is a reference to a line only selects rows that contain certain numbers in a specific coloumn, "M", the criteria for this is anything below 1.3, so if any thing, the table would get smaller surely?

This is the code for MParam:

MParam = M < 1.3;

[Michael Soskind]

My guess is that MParam has more rows than the new variable of SF2. This is possibly because you need something that has the same number of rows as the original M matrix to index with MParam.

[dpb]

"MParam is a reference to a line only selects rows that contain certain numbers in a specific coloumn,..."

Typical usage. Yes, the total number of elements selected is likely less (maybe even only one), but that doesn't have any bearing on which row they/it was in in the table from which it was selected. You've returned the row in that table or array and if it has more rows than does SF2, then you can get the mismatch.

Of course, if the found locations all had happened to have indices <= height(SF2), the operation would have worked silently, but in all likelihood not have provided the result expected -- you would have referenced values according to a position in one table with different rows than the one to which you applied those indices.

We don't haven't sufficient info to know what the intent of the operation is and so can't really tell you how to code for what you want to accomplish precisely, but that is the problem and the cause of the error.

It's very easy to illustrate what happened...

>> x=randi(10,100,1);
>> y=x(x>=2);
>> whos x y
  Name        Size            Bytes  Class     Attributes

  x         100x1               800  double              
  y          91x1               728  double              

>> ix=find(x>3);
>> whos ix
  Name       Size            Bytes  Class     Attributes

  ix        70x1               560  double              

>> z=y(ix);
Index exceeds the number of array elements (91). 
>> sum(ix>numel(y))
ans =
     6
>> 

Here I used an array instead of going to trouble to make a table, but same issue. I created a second array that is a subset of x, ergo shorter, then tried to reference into it with indices from the first. BOOM! As shown, there were 6 elements in the index vector that were outside the bounds of the shorter array.

The above is of course artificial so we don't know how you built the arrays you're referencing or what you're trying to do for sure, but probably you need to do some indirect addressing so you are always referencing back to the number of and position in the array from whence the indices were derived.

The second point made above can be illustrated by changing the example just a tiny little bit code-wise, but huge difference in result...

>> ix=find(sort(x,'descend')>3);
>> z=y(ix);
>> 

Here I forced the high numbers to the beginning of the array before selecting and so all the indices turned out to be <numel(y) and so the operation succeeded. Similarly, by happenstance or other reasons of how the data were generated, you could have run across the same thing in earlier cases where it just so happened that the looked-for values were all located early enough in the searched-in array to have been found within confines of the second. Or the second could have been longer or long-enough by how it was created...

[Ewan Compton]

Oh, so you are saying to fix this I just use your latest code and itll order the numbers correctly because the code wont sort past a certain distance? If so, what determines this difference?

[dpb]

No, I'm not saying that at all...I'm showing you the probable cause of your problem -- we can't know the correct solution lacking any more information on what you're trying to do.

Sorting in your case is almost certainly NOT the correct one...just a machination I used to show the difference one can get depending on data placement between same code with different data.

Reread the explanation and experiment with a sample set of data small enough to examine at command window to fully comprehend the problem.

Answer 1

[Image Analyst]

This works:

% Create table (because user forgot to attach it).
numRows = 20;
col1 = 2 * rand(numRows, 1);
col2 = 2 * rand(numRows, 1);
SF2 = table(col1, col2)
% Now we have our table and can begin

% Extract column 1 into a column vector M
M = SF2.col1
% Figure out which rows have a value of less than 1.3:
rowsToExtract = M < 1.3
% Extract only those rows into SF3:
SF3 = SF2(rowsToExtract, :)
whos SF3 % Show size of SF3

No error at all. If it doesn't work for you, then attach SF2 in a .mat file

save('answers.mat', 'SF2', 'M');

and attach to your reply.

[Ewan Compton]

From what I understand of that code, it takes thee table appart, I need to keep the information together because im limitting a set of results to find the select few that comfor to a list of criteria, splitting it up and just finding out what i need in that section would just leave the other information, separte from this peice of criteria and vice versa

[dpb]

Again I repeat and reiterate -- you are refusing to show us context of how you got your index vector -- IA illustrated that IF you use the index vector on the array from which it was computed the indices will be self-consistent. But in your case you clearly didn't do that or you wouldn't have had the indexing error.

If you just made a typo and wrote

SF3 = SF2(MParam,:)

where SF2 is a typo for some other table name (another reason why using sequentially named variables can lead to coding/logic errors and is recommended against for most cases) that is of the same size as that which was used to calculate MParam, then just fix the typo and go on.

If, otoh, you are trying something more complex than what IA just illustrated, then there's bound to be a way to do it but we need to know what it is specifically that are trying to do. Context is important; we can't see the code that created MParam so we're flying blind and guessing, mostly. (Highly educated guesses, yes, but still based on presumptions, not actual data).

IA's answer doesn't "break up" the table; he just brought the array M out for illustration to make variables that seemed to match up some with your naming (did I mention you haven't shown us how you did that yet?)--it can be done just as well w/o the additional array:

>> % Create table (because user forgot to attach it).
numRows = 20;
col1 = 2 * rand(numRows, 1);
col2 = 2 * rand(numRows, 1);
SF2 = table(col1, col2);
>> SF3=SF2(SF2.col1<1.3,:)
SF3 =
  16×2 table
      col1        col2  
    ________    ________
      1.2441     0.77948
      0.7019     0.48338
      1.0265     0.80782
     0.80362     0.19291
     0.15193     0.26395
     0.47983      1.8841
     0.24664      1.9123
     0.36782      1.1504
     0.47991     0.11956
     0.83453     0.46956
    0.099309     0.70632
     0.98173    0.086048
     0.97851     0.33798
     0.67544      1.2982
     0.73849      1.2955
     0.22241     0.90185
>> whos SF*
  Name       Size            Bytes  Class    Attributes

  SF2       20x2              1592  table              
  SF3       16x2              1528  table              

>> 

which does the same operation without any intermediate variables including the explicit logical indexing variable (or indices variable if you used find).