When can’t MATLAB add up?

April 29th, 2010 | Categories: math software, matlab | Tags:

I have got a nice, shiny 64bit version of MATLAB running on my nice, shiny 64bit Linux machine and so, naturally, I wanted to be able to use 64 bit integers when the need arose.  Sadly, MATLAB had other ideas.  On MATLAB 2010a:

a=int64(10);
b=int64(20);
a+b
??? Undefined function or method 'plus' for input arguments of type 'int64'.

It doesn’t like any of the other operators either

>> a-b
??? Undefined function or method 'minus' for input arguments of type 'int64'.

>> a*b
??? Undefined function or method 'mtimes' for input arguments of type 'int64'.

>> a/b
??? Undefined function or method 'mrdivide' for input arguments of type 'int64'.

At first I thought that there was something wrong with my MATLAB installation but it turns out that this behaviour is expected and documented. At the time of writing, the MATLAB documentation contains the lines

Note   Only the lower order integer data types support math operations.
Math operations are not supported for int64 and uint64.

So, there you have it. When can’t MATLAB add up? When you ask it to add 64 bit integers!

Update: Just had an email from someone who points out that Octave (Free MATLAB Clone) can handle 64bit integers just fine

octave:1> a=int64(10);
octave:2> b=int64(20);
octave:3> a+b
ans = 30
octave:4>

Update 2: Since I got slashdotted, people have been asking why I (or, more importantly, the user I was helping) needed 64bit integers. Well, we were using the NAG Toolbox for MATLAB which is a MATLAB interface to the NAG Fortran library. Some of its routines require integer arguments and on a 64bit machine these must be 64bit integers. We just needed to do some basic arithmetic on them before passing them to the toolbox and discovered that we couldn’t. The work-around was simple – use int32s for the arithmetic and then convert to int64 at the end so no big deal really. I was simply surprised that arithmetic wasn’t supported for int64s directly – hence this post.

Update 3: In the comments, someone pointed out that there is a package on the File Exchange that adds basic arithmetic support for 64bit integers.  I’ve not tried it myself though so can’t comment on its quality.

Update 4: Someone has made me aware of an interesting discussion concerning this topic on MATLAB Central a few years back: http://www.mathworks.com/matlabcentral/newsreader/view_thread/154955

Update 5 (14th September 2010): MATLAB 2010b now has support for 64 bit integers.

  1. tom
    April 29th, 2010 at 13:55
    Reply | Quote | #1

    what is the point of having numerical data types that can’t be manipulated? What can matlab do with 64bit integers?

  2. April 29th, 2010 at 13:56
    Reply | Quote | #2

    @tom Quite! It can store them. Move them around. Pass them to mex files. um….that’s it I think.

  3. April 29th, 2010 at 18:44
    Reply | Quote | #3

    Laughs out loud…..Amazing! I hope they are not promoting the 64bit-ness!

  4. May 3rd, 2010 at 02:00
    Reply | Quote | #4

    It’s a problem in the fact that they follow the IEEE std 754 which basically allows for only 52 of the 64 bits for the mantissa (full break down below):

    1. Assume 64 bits are allocated to a number,
    2. Assume the LSB is N1 (to match with Matlab/Octave nomenclature), MSB is N64
    3. Then N1 is used as a sign bit
    4. N2-N13 are used to store the exponent (ranging from -1021 to 1024)
    5. The remaining bits 52 are used to store the mantissa (the fractional component)

    It stinks – there are work around – but they aren’t pretty.

  5. mcg
    May 3rd, 2010 at 02:04
    Reply | Quote | #5

    As you surely know, MATLAB first and foremost is a double-precision floating point algorithm platform. Next in importance for its target market is its fixed-point support for real-world signal processing and control design apps. But in such cases, widths larger than 32 bits are rare, and anything between 33 and 53 bits can be emulated quite efficiently in floating point.

    It would be silly to assume that 64-bit integers would just “work” by recompiling the code on a 64-bit platform. (That is not an accusation that *you* are silly :)) They have to be implemented explicitly, and of course they’ll only do so if their market research detects enough of a demand for them. (Indeed, templated code would simplify their implementation, but MATLAB is old enough that I’d be surprised if they employ templates in their core computational code. I would *not* want them reinventing the wheel just to adopt the modern technologies, either.)

    So while I admit the “64-bit” repetition in your blog text is cute, I’m curious as to precisely what application you’re thinking of 1) calls for 64-bit integer support, and 2) would be well suited for MATLAB implementation (if it could be done). I’m going to guess that application is somewhat unique. And I’m glad to hear that Octave will do it for you.

  6. Simon
    May 3rd, 2010 at 02:10
    Reply | Quote | #6

    The documentation does mention this as a limitation:
    “Note: Only the lower order integer data types support math operations. Math operations are not supported for int64 and uint64”

    A bit more digging reveals that you can write them to a file (fwrite), use them with imreconstruct, and pass them off to mex, java and C#. I’m sure it’ll eventually turn up in a few releases time…

  7. mcg
    May 3rd, 2010 at 02:13
    Reply | Quote | #7

    OK, just want to make a couple things clear. First I don’t work for the Mathworks, never have. I do have an optimization toolbox developed on the platform, though, and I can tell you that I am as frustrated sometimes by Matlab’s limitations and bugs as anyone. I’m in the process of spec-ing out the next version of my system so that it can be effectively divorced from Matlab.

    And second I don’t wish to denigrate you or your work. I’m genuinely curious what applications would make heavy use of 64-bit integers. And I genuinely hope you’ll

    My point is simply that Matlab’s 64-bit compilation and support for int64 computations are really two different issues. 32-bit Matlab should be able to support 64-bit computations, too, as long as there are a lot less than (2^32-1)/8 of them!

  8. mcg
    May 3rd, 2010 at 02:14
    Reply | Quote | #8

    OK, just want to make a couple things clear. First I don’t work for the Mathworks, never have. I do have an optimization toolbox developed on the platform, though, and I can tell you that I am as frustrated sometimes by Matlab’s limitations and bugs as anyone. I’m in the process of spec-ing out the next version of my system so that it can be effectively divorced from Matlab.

    And second I don’t wish to denigrate you or your work. I’m genuinely curious what applications would make heavy use of 64-bit integers. And I genuinely hope you’ll find a good platform for your work in that area.

    My point is simply that Matlab’s 64-bit compilation and support for int64 computations are really two different issues. 32-bit Matlab should be able to support 64-bit computations, too, as long as there are a lot less than (2^32-1)/8 of them!

  9. Martin Conway
    May 3rd, 2010 at 03:05
    Reply | Quote | #9

    I believe the main (only?) advantage of 64bit Matlab is that gets past the 32bit memory limit. This enables you to work with much larger sets of data (not 64bit data apparently).

  10. batman
    May 3rd, 2010 at 03:15

    >> methods int64

    Methods for class int64:

    abs diag ge le nnz reshape uplus
    accumarray display gt linsolve nonzeros round xor
    and eq imag logical not sort
    bsxfun find isfinite lt nzmax sparsfun
    ceil fix isinf max or transpose
    conj floor isnan min permute tril
    ctranspose full issorted ne real triu

    >> methods uint64

    Methods for class uint64:

    abs bitxor find isinf min real uplus
    accumarray bsxfun fix isnan ne reshape xor
    and ceil floor issorted nnz round
    bitand conj full le nonzeros sort
    bitget ctranspose ge linsolve not sparsfun
    bitor diag gt logical nzmax transpose
    bitset display imag lt or tril
    bitshift eq isfinite max permute triu

  11. May 3rd, 2010 at 04:04

    On my version of GNU Octave (3.0.5, x86_64-pc-linux-gnu, Ubuntu Lucid)

    octave:1> a = int64(10)
    a = 10
    octave:2> b = int64(10)
    b = 10
    octave:3> a+b
    error: binary operator `+’ not implemented for `int64 scalar’ by `int64 scalar’ operations
    error: evaluating binary operator `+’ near line 3, column 2
    octave:3>

  12. May 3rd, 2010 at 04:19

    Sorry, I naively assumed that lucid would have a recent version of octave. It seems octave 3.2 has been out for nearly a year, and does implement 64-bit int support.

  13. Anthony
    May 3rd, 2010 at 04:34

    I actually wrote an extension to do that:
    http://www.mathworks.com/matlabcentral/fileexchange/21883-image-processing-subset

    It does a pretty good job. Its not native matlab persay, but the code is competitivly fast and works with all data types. It also looks for overflows, etc…

  14. May 3rd, 2010 at 05:49

    Geez, am I glad I switched to Python/NumPy:

    >>> from numpy import *
    >>> int64(10) + int64(20)
    30
    >>> _.dtype
    dtype(‘int64’)

  15. Andrew
    May 3rd, 2010 at 05:57

    It runs in a 64 bit memory space, so you can have arrays bigger than 2^16 x 2^16. I don’t know if it can index beyond 2^32 … someone should test that. I think only 40 address bits are actually hooked up on modern CPU’s ?

  16. Erick
    May 3rd, 2010 at 07:58

    Not so long ago, MATLAB couldn’t do arithmetic with any type except double (maybe also float, I don’t recall). At that time one could only perform arithmetic by first converting to double, though this would be a lossy operation for 64-bit, unlike prior cases. So this shouldn’t surprise any MATLAB veteran.

    One potential explanation might be that they are taking some time to support 64-bit ints in the JIT compiler (a feature that the much slower-performing Octave clearly lacks).

  17. yacc
    May 3rd, 2010 at 11:22

    @Andrew

    Well, it’s not that much relevant how much is hooked up, for some algorithms ultra fast swap (be it RAM or flash based) can be fine enough.

  18. Ben
    May 3rd, 2010 at 12:29

    I’m pretty sure this is to do with the majority of MATLAB core functions being handled by the Intel MKL. To code around this, I expect there would have to be a heck of a lot of case handling that would impact on performance. If you want arbitrary integer handling I would suggest casting / passing a pointer to something like the GNU MP Bignum Library to handle this case.

  19. Anthony
    May 3rd, 2010 at 12:59

    Matlab supports 64 bit types, the built in functions just haven’t been expanded to properly manipulate them. Again, take a look at the link I put up earlier – you can do it and it will work. If you need more you just need to do a bit of work on it…

    Truthfully, I don’t think it would be all that difficult to add even bigger numbers than 64 bit. Again, the only problem is the built in functions depending on what you want to do and your skill set…

    BTW – the JIT only works on m scripts. A great deal of the code that needs to be updated to fully support 64 bit isn’t m script – its C, C++, or Java.

    Anthony

  20. Bill
    May 3rd, 2010 at 17:52

    “On my version of GNU Octave (3.0.5, x86_64-pc-linux-gnu, Ubuntu Lucid)”

    It works fine on GNU Octave 3.2.3

    octave:1> a= int64(10)
    a = 10
    octave:2> b = int64(20)
    b = 20
    octave:3> a+b
    ans = 30

    “And second I don’t wish to denigrate you or your work. I’m genuinely curious what applications would make heavy use of 64-bit integers. And I genuinely hope you’ll find a good platform for your work in that area.”

    We use them a lot in orbital mechanics. If you use the center of the Earth as your origin, and need high precision in meters, (we do) then having double precision and 64 bit math is important. Right now we do a lot of code in fortran and C/C++, but it would be nice to have more tools that have the capability. We do use Matlab as a solver, but it would be nice to be able to do more in Matlab.

  21. May 3rd, 2010 at 18:43

    I’ve been following this discussion with interest, and wanted to chime in to help describe the different meanings of “64-bits” in MATLAB. You can use it to refer to the amount of memory available to MATLAB or your operating system, the number of elements allowed in a matrix, or to an integer data type.

    64-bit operating systems give us 64 bit address space. This gives MATLAB the ability to store many more arrays in memory, or even a few really large arrays. In practice, you need A LOT of memory to support working with arrays this large:

    >> x = zeros(2^31,1); % requires 17 GB

    In addition, indices for arrays in MATLAB can now exceed the previous INTMAX (2^31-1) value of 32 bit OS’s. Now the maximum theoretical limit is 2^48-1 on 64-bit platforms, but not many people have the memory to create:

    >> x = zeros(2^45-1,1); % requires 280 Terabytes
    ??? Out of memory. Type HELP MEMORY for your options.

    One easy way to observe the new index limit is in sparse matrices, which only store individual row indices:

    >> S = sparse(2^48-1,1,17)
    S =
    (281474976710655,1) 17

    Finally, there is the 64-bit integer data type, which currently exists as a storage class only in MATLAB, with several dozen non-mathematical operations like indexing, concatenation, reshaping, permuting, and so on.

    We’re interested in hearing customer requests for uses of 64-bit integer math in MATLAB that are not satisfied by the 32-bit integer or 64-bit floating point data types. Thank you for your interest and feedback.

    Penny Anderson
    MATLAB Math
    MathWorks

  22. May 3rd, 2010 at 22:17

    Hi Penny

    Thanks for the insightful comments. As I put in Update 2 of the original post, the only reason I needed 64bit integers was because an external library expected to have them as input arguments. In my particular application I worked around the lack of 64bit operators by doing my arithmetic with int32s and then cast to int64 at the end. This worked fine but looked inelegant.

    So, if I am being honest, I didn’t NEED 64bit integers – it just would have been nice. Reading through the comments both on here and on slashdot, it seems that others are not so lucky.

    However, I wonder how much work would it be to implement addition and subtraction for int64s? If it would be difficult then could you share with us what the complications are please?

    Cheers,
    Mike

  23. Eddie M
    May 3rd, 2010 at 23:12

    I find all fuss about MATLAB amazing. OK, so someone found a problem with MATLAB that ought to be fixed. So what? Bugs are reported to the MW continuously on every imaginable MATLAB and Simulink product – and there are close to 100 (R2010a). Report the bug or problem to the MW and they will do everything they can to fix the problem. I have developed MATLAB applications and Simulink models professionally for +15 years. Every year I report at least one bug (that has yet to be reported) and each time the bug has been fixed in future versions. The MW goes out of its way to respond to feedback of its customers and I am sure what has been posted here will be no exception.

  24. May 3rd, 2010 at 23:23

    Hi Eddie

    I completely agree – The Mathworks are extremely good at responding to feedback from customers. I just like to post some of my feedback in blog-posts on here if I think that it might be interesting to other people. I report plenty of other bugs via the usual channels – most of them are not interesting enough to write about on here. Mathworks always fix them quickly and I’m a happy customer (most of the time).

    I find this sort of stuff intrinsicly interesting that’s all.

    Cheers,
    Mike

  25. GG
    May 4th, 2010 at 20:11

    I agree that MathWorks does an extremely good work in fixing bugs in future versions. But who has the money to constantly buy new licenses?

    That’s why A LOT of people are switching (or at least try) to python, sage etc.

    P.S. Why they don’t make free patches for current versions? (correct me if I’m wrong)

  26. May 6th, 2010 at 19:28

    No int64 arithmetic in Matlab? Maybe that is better than having slow int32 arithmetic.

    Here is an extract from a comment by John D’Errico on Matlab’s File Exchange (FEX):

    ————————————————–
    “Use of int32 instead of double would be a tremendously silly thing to do, since int32 operations are not even faster than operations on doubles! In fact, use of int32 would slow down this code!

    >> N = int32(1:10000);
    >> P = int32(23);
    >> timeit(@() mod(N,P))
    ans =
    0.0036231

    >> N = double(1:10000);
    >> P = double(23);
    >> timeit(@() mod(N,P))
    ans =
    0.0026903

    In fact, arithmetic using doubles is FASTER than int32 arithmetic. int64 or uint64 arithmetic is not even defined in the target release, so the speed is incomparable there.”

    http://www.mathworks.com/matlabcentral/fileexchange/23846-nextprime

    —————————————-

    Remember: In Matlab you can have any type you want as long as it’s a double.

    Regards,

    Derek O’Connor

  27. May 8th, 2010 at 07:55

    I had forgotten that I had my own example of how slow Matlab’s
    int32 arithmetic can be:

    function p = ShuffleP3264(n,wbits);
    % This shows the difference between Matlab’s
    % normal 64-bit double ‘integers’ and 32-bit int32 ‘integers’.
    %
    % Generate a random permutation vector p(1:n) using
    % Knuth’s Algorithm P, Section 3.4.2, TAOCP, Vol 2, 2nd Ed.
    % Derek O’Connor, 30 Mar 2010

    if wbits == 32 % This type propagates below and
    n = int32(n); % causes a big slowdown
    end;
    p = 1:n;
    for i = n:-1:2
    r = floor(rand*i)+1; % random integer between 1 and i
    t = p(r);
    p(r) = p(i); % Swap(p(r),p(i))
    p(i) = t;
    end;
    return; % ShuffleP3264

    % TEST
    % clear all
    % tic;p = ShuffleP3264(10^7,64);toc
    % Elapsed time is 2.005458 seconds.
    %
    % clear all
    % tic;p = ShuffleP3264(10^7,32);toc
    % Elapsed time is 24.762971 seconds.

    On this problem int32 arithmetic is 12 times slower than the default ‘double integers’. This means that I can have really huge int32 arrays but I can’t do anything with them.

    Derek O’Connor.

    Matlab 7.6.0.324 (R2008a) 64 bit
    Dell Precision 690, Intel 2xQuad-Core E5345 @ 2.33GHz
    16GB RAM, Windows7 64-bit Professional.

  28. June 8th, 2010 at 14:21

    For those MathWorks customers on maintenance, try out the R2010b Prerelease, as announced yesterday:

    http://www.mathworks.com/matlabcentral/newsreader/view_thread/284070#752400

    64-bit integer arithmetic support is included.

    Penny Anderson
    MathWorks

  29. June 8th, 2010 at 16:42

    Hi Penny

    That’s great news – thanks :)

    Best Wishes,
    Mike

Comments are closed.