Abfload error - colon operands must be real scalars

Hi all, we've had to transfer some Matlab code to a new computer for analysis of .abf files and moved from version R2018b to R2025a. However abfload is now giving us the error message below. Can anybody suggest a work around? The error message is below.

Error using :

Colon operands must be real scalars.

Error in

abfload (line 304)

h.protocolName=char(BigString(tmpIx1:tmpIx2(1)+3))';

^

[Matt J]

What do you want that line to do? Why is tmpIx1 not a scalar?

[Simon]

Hi Matt - thanks for the quick reply. As I understand it tmpIx1 is generated from a protocol file associated with the .abf file. However, good news - the issues seems to be with the switch to R2025a and has been resolved by reverting to R2018b.

[Matt J]

I don't see how that's good news. The whole reason for your post was that you wanted to upgrade to R2025.

[Walter Roberson]

I suspect that tmpIx1 might have been derived from a find() or strfind() of something that turned out to have multiple matches where only a single match was expected.

Answer 1

[Matt J]

Replace with,

 h.protocolName=char(BigString(tmpIx1(1):tmpIx2(1)+3))';

Answer 2

[Steven Lord]

the issues seems to be with the switch to R2025a

No, the issue is that you're trying to use the colon operator with complex numbers and/or with values that are not scalar. Since the name tmpIx1 and its usage on the line where the error occurs imply to me that these are indices, the problem is more likely the non-scalarness than the complexity.

In release R2024a we started issuing a warning for non-scalar inputs to the colon operator, as stated in the Release Notes. MATLAB would ignore everything but the first element of the non-scalar inputs (and return the 1-by-0 empty row vector if the input was empty.) That might be what you intended, but all too often we saw that it indicated that you may not be aware of what you were actually doing. What do you think this used to do?

A = ones(3, 4);
% Leaving this block commented out so I can run more code later in the post
%{
x = 1:size(A)
%}

What it did was take the first element of the vector returned by size(A), in this case 3, and completely ignore the second element, 4. So x would be 1:3. Did you actually intend for x to be the vector of row indices? Or did you actually intend for it to be 1:4 like:

x = 1:size(A, 2)

x = 1×4

1 2 3 4

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

or 1:12 (for use in iterating over all the elements of A?)

x = 1:numel(A)

x = 1×12

1 2 3 4 5 6 7 8 9 10 11 12

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

By the way the way to get the previous behavior, where MATLAB uses the size in the first dimension, is to pass 1 in as the dim input to size. You could also use the height or width functions to get the number of rows or columns of the array.

x = 1:size(A, 1)

x = 1×3

1 2 3

<mw-icon class=""></mw-icon>

<mw-icon class=""></mw-icon>

In release R2025a we turned that warning from the colon operator into an error, again as stated in the Release Notes that I linked above.

The solution is to make the abfload function use scalars on that line of code by asking for the first element of tmpIx1, as shown by Matt J.

 %{
h.protocolName=char(BigString(tmpIx1(1):tmpIx2(1)+3))'; % Both uses of (1) are necessary!
 %}

[Simon]

Thank you for the explanation!