Asked by Doug Rank
on 3 Sep 2019

According to the bottom answer on this link, the reason why Matlab hasn't included support for matrix multiplication on integer types is because it relies on low-level MKL operations to perform linear algebra operations. And until recently, MKL did not support matrix multiplication on integer types. But MKL 2018 now includes such support.

Given the machine-learning applications (or my optimization project which requires tons of integer matrix multiplication as fast as possible), are there any plans to include support for this in upcoming Matlab releases?

Answer by James Tursa
on 3 Sep 2019

The main problem with matrix multiplication on integer types (int32, etc.) in MATLAB is that the operation result is ambiguous in general and the outcome relies totally on the order of operations you perform ... you can get a different result by doing the operations in a different order. This is because arithmetic on integer types in MATLAB uses truncation rather than "clock" arithmetic (mod). E.g., take this simple example:

>> x = int8([10 10 -10])

x =

10 10 -10

>> y = int8([10;10;10])

y =

10

10

10

>> x*y

Error using *

MTIMES is not fully supported for integer classes. At least one input must be scalar.

To compute elementwise TIMES, use TIMES (.*) instead.

OK, so that's the expected error since the operation isn't supported. Now let's do the same operatioin manually in two different ways:

>> (x(1)*y(1) + x(2)*y(2)) + x(3)*y(3)

ans =

27

>> x(1)*y(1) + (x(2)*y(2) + x(3)*y(3))

ans =

100

There are two different answers you can get depending on the order of calculations. This is a direct result of the truncation rules for integer type arithmetic in MATLAB.

MATLAB likely will never support matrix multiplication on integer types because of this ambiguity. Background routines that change the order of calculations for speed purposes and thread availability can get different answers for the exact same inputs if they followed the MATLAB truncation rules for arithmetic ... not a good thing.

Doug Rank
on 3 Sep 2019

Thank you for your reply and the good example.

I'm assuming doing MKL uses unpredictable order of operations (as opposed to just doing them sequentially) for optimization? Because otherwise I would just stick one order of operations to remove ambiguity and call it a day.

Regardless, that only covers half the playing field. My application (and I expect plenty of others) only needs to use unsigned ints as it represents some physical unit. Applying your example to uint8 (and changing 10 to 100) gives the same result in both cases: 255.

Since matlab defaults to double anyway, shouldn't the onus be on the programmer to decide if it would be an issue (for unsigned int, at least)? Integer overflow and Floating Point imprecision are pretty much required knowledge for any programmer.

Walter Roberson
on 3 Sep 2019

Unfortunately we end up having to explain floating point precision issues every few days here...

James Tursa
on 3 Sep 2019

Unsigned integer type arithmetic in MATLAB suffers from the same truncation effect (they don't use "clock" or "mod" arithmetic), but yes the result ambiguity is removed for these types.

Note that although the result ambiguity is removed for unsigned types, this truncation is still extra work. Compiled languages such as C/C++ would typically simply ignore all overflows for integer arithmetic ... essentialy reducing the operation to the "clock" or "mod" rules. Note that this is required behavior for unsigned integers in C/C++, and although not required for signed integers it is typically how it is implemented because it is less work (there is no overflow checking involved). Maybe MKL has notes on how they handle integer overflow.

"I'm assuming doing MKL uses unpredictable order of operations (as opposed to just doing them sequentially) for optimization?"

I would assume the same thing.

Sign in to comment.

Opportunities for recent engineering grads.

Apply Today
## 0 Comments

Sign in to comment.