Integers in Arrays Give Strange Result

For example, try this,

vec = [pi, -2, uint8(1)]
vec =
  1×3 uint8 row vector
  3   0   1

vec = [pi, uint16(2), int8(-2)]
vec =
   1×3 uint16 row vector
   3   2   0

vec = [pi, uint16(2), int16(-2)]
vec =
   1×3 uint16 row vector
   3   2   0
   

So, if one element is an integer MATLAB seem to cast every other element in the array to that integer class. If there are several integer elements all elements seem to be cast to the higher integer class and, in a draw, to the unsigned class.

This is an extremely odd behavior. One would expect all elements to be cast to a numeric class that can accurately represent all elements or, at least, all elements cast to 'double' if there are mixed numerical classes in the array.

This can lead to totally wrong results if a user supplies integers to a function, for example this one,

   function y = myFun(x, k)
   
   par = [k, -2];
   y   = par(1) + par(2)*cos(x); 
   
   end

myFun(0, 1) will give -1 and myFun(0, uint8(1)) will give the incorrect result 1.

So, is there some logic behind this behavior or is it a bug?

Answer 1

[Steven Lord]

For concatenation see this documentation page. If you concatenate one or more integer arrays with one or more double arrays, the leftmost of the integer arrays will determine the type of the result.

For the behavior of arithmetic see this documentation page.

This is the documented behavior and has been for many years. It is not a bug.

[the cyclist]

Nit-pick of this correct solution: It is actual this documentation page that specifies what happens when a double is combined with an integer.

I am sympathetic to @Patrik Forssén's question, though. It is clearly not a bug (as it is documented behavior), but the documentation doesn't seem to give the reasoning behind the rule. Personally, I find it difficult to internalize the rules when I don't understand the reasoning.

[Patrik Forssén]

Thank you for the answer! Though it is documented, I still fail to see the logic behind this integer behavior. This makes the integer classes of very limited use, and one should generally make sure that they are not present in calculations and when manipulating arrays.

[the cyclist]

Obviously it's a matter of opinion, but I think your sweeping dismissal of the utility of integer classes is too broad.

MATLAB has to make some rule about what to do when these integers classes are combined — but I think combining different classes is simply not a typical use case. I expect it is vastly more common to be doing entire swaths of calculations on a single class, and the memory savings of having these classes is significant.

I also think it is reasonable to expect a user who is combining classes to research the documentation to learn how it works, rather than to just assume how it works.

[Bruno Luong]

" I still fail to see the logic behind this integer behavior"

I guess the logic is to ease the parser/EE: it is no need to bother fo figure out the largest/smalest integer classes in complex expression, where the class of variables can be burried deep inside the expression and then the parser need to do two pass.

The "mostleft" rule will fix the class once, then everything else will be casted later by the parser with the detected class of the mostleft.

Remember those rules are made long ago and the performance on slow hardware is the priority.

If you want to control the class, you can do explicit cast on your data.

At least that what I would do and not rely on the strange rule and the order of the expression.

For fun, these expressions return the same numerical values but different class because they are written in different cat order. The elements are the sames just shuffled around by cat order.

(EDIT I don't know what happens the first time I post it, now it is correct class(M2) is 'uint16') different class(M1))

M1 = [1 uint8(8); 2 3; uint16(16) 4]

M1 = 3×2

1 8 2 3 16 4

M2 = [[1; 2; uint16(16)] [uint8(8); 3; 4]]

M2 = 3×2

1 8 2 3 16 4

class(M1)

ans = 'uint8'

class(M2)

ans = 'uint16'

[Walter Roberson]

The conversion is to the most restricted combination of elements. So if any of the entries are unsigned then the result is unsigned, and the number of bits is the smallest among the possibilities.

[Steven Lord]

@the cyclist You are correct. The link I posted just covers combining different integer types and doesn't cover combining integer and non-integer data. I thought I remembered it also briefly touching upon integer and non-integer data, but I must have been thinking about the arithmetic page.

[Paul]

@Walter Roberson

Looking at M2 in Bruno's example and the doc page linked by the cyclist, the leftmost integer type governs, not the signedness nor smallest [number of bits] type when concatenating doubles with integer types, IIUC.