Integers in Arrays Give Strange Result

Question

Patrik Forssén 2022-11-15

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1850958-integers-in-arrays-give-strange-result

编辑： Bruno Luong 2022-11-15

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?

0 个评论
显示 -2更早的评论隐藏 -2更早的评论

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Steven Lord 2022-11-15

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/1850958-integers-in-arrays-give-strange-result#answer_1099858

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.

7 个评论
显示 5更早的评论隐藏 5更早的评论

Bruno Luong 2022-11-15

编辑：Bruno Luong 2022-11-15

在 MATLAB Online 中打开

" 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'

Steven Lord 2022-11-15

@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 2022-11-15

@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.

请先登录，再进行评论。