Index out of bounds using "length"

Hi, I have a loop that references a 1x82 data structure. Each matrix, "CF(i).SincIncep", has a different number of rows but all have 4 columns; therefore, I am using the length command for each "i" in order to get the unique number of rows for the calculation. The problem is, I am getting an index out of bounds error which I do not understand as the actual matrix referenced in the error is stored as a 3x4 double. The length command results in the correct length for the majority of the calculations in the loop, but not for the one mentioned, which says the length is 4. I am not sure why the "length" command would state there are 4 rows when there are only 3 rows in the matrix. I tried using "size" instead; however, it does not make sense to me why the "length" command would work correctly for some and not for others as all matrices are mx4. The loop I am using is below along with the error output:

for i = 1:82;
  for n = 1:length(CF(i).SincInc);
    for j = 2;
      CF(i).SincInc(n,j+2) = CF(i).SincInc(n,j) + CF(i).SincInc(n,j+1);
    end
  end
end

Attempted to access CF.SincInc(4,2); index out of bounds because size(CF.SincInc)=[3,4].

Answer 1

[Star Strider]

The length command will return the value of the largest dimension. If you want to be certain to only return the number of rows, use the size function, specifically size(x,1):

for n = 1:size(CF(i).SincInc, 1);

Answer 2

[dpb]

WAD.

length   Length of vector.
  length(X) returns the length of vector X.  It is equivalent
  to MAX(SIZE(X)) for non-empty arrays...

Note you've got an array size(3,4) --> max(3,4) ==> 4. Hence, length --> 4, not 3.

It's an unfortunate "feature" in some ways that length isn't equivalent to size(x,1) for 2D arrays but that's "just the way it is". Note also that the help says it is length of vector X; which is a 1D array, not 2D.

The moral of the story is if you want size(array,1), use that expression instead of length. It's far safer even if needs another argument in the calling expression.

[dpb]

Just as a note, while using them seems to have fallen out of favor in my coding style although not by specific decision, many years ago because it bugged me I built a couple of utility functions nrows and ncols precisely to not have to use the size argument. They, of course, have more execution cost as a price to pay for the simpler-looking high-level code. Generally, this isn't anything to bother with as, is in your case, it's a single call to set a constant for a loop iterator or such. Buried inside a deeply nested loop might in other circumstances become an issue...

[Image Analyst]

Or, one could make the argument that length() should be the same as numel() for multi-dimensional arrays.

[dpb]

Yeah, that'd be the one alternative.

In reality, length is one of the few oldtimers I'd like to see deprecated in favor of inbuilt nrows ncols in lieu. It ( length) is just too error-prone as illustrated and too much the likely candidate by name so as to cause such errors automagically. The kicker with it is, of course, that it works sometimes and sometimes doesn't to the intended result since it's data-dependent.

It even showed up in the bug in an earlier release of interp1 wherein it didn't interpolate down multiple columns if there were more columns over which to interpolate than the length of the interpolating vectors.

[Walter Roberson]

However, using nrows and ncols would require that users pay attention to the orientation of their vectors, which is often not something that needs to be thought about.

[dpb]

There's that, too, which is undoubtedly where the definition came from as is implied by the help files. It's when applied to other than vectors it becomes an issue so maybe it should stay but perhaps evolve to only work for vectors in its new guise...or mayhaps have differing behavior of

if isvector(x)
  len=max(size(x)); % vector length if is vector
else
  len=size(x,1);   % anything other than vector use row direction
end

Not that it's likely to change; too much existing baggage.