# MKL 2018 supposedly supports integer matrix multiplication. Can this feature be added to Matlab?

5 views (last 30 days)
Doug Rank on 3 Sep 2019
Edited: James Tursa 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?

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

R2017b

### Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!