MATLAB Can't Manipulate 64-Bit Integers

An anonymous reader writes "MATLAB, an important package of mathematical software heavily used in industry and academia, has had support for 64-bit machines for several years now. However, the MATLAB developers still haven't gotten around to implementing even basic arithmetic operations for 64-bit integers. Attempting to add, divide, subtract, or multiply two 64-bit integers will result in an error message saying that the corresponding method does not exist. As one commentator put it, 'What is the point of having numerical data types that can't be manipulated?'" The post notes that the free MATLAB clone GNU Octave deals with 64-bit integers just fine.

Comments

It's not that big of deal

[Anonymous Coward]

Given that many values used in calculations are enormous, potentially thousands of bits long, 32 bits is quite sufficient. So long in fact, they can only be stated as 'strings' of integers. So much for different data types!

The concern should be the amount of time required to complete a calculation which MATLAB is very good at. I'd guess MATLAB is optimized for 32 bit. What is to be gained by rewriting everything for 64 bit?

So long as all calculations are done in a timely manner.

Re:It's not that big of deal

[wizardforce]

If you're a physicist and you wanted to do calculations that involved a few coulombs of charge worth of electrons, MATLAB would throw out an error as this mathematical operation in particular happens to require the calculation of a ~64 bit integer and not be terribly unreasonable.

Re:It's not that big of deal

[Jeffrey Baker]

I think you're right, and I see the same kind of thinking when I ask about 64-bit integers in R. The people who use R are statisticians who can't imagine why a double isn't close enough. The people who complain about it are the computer programmers who are trying to use 64-bit exact fields to merge two datasets etc.

Re:It's not that big of deal

[spikenerd]

You mean like Octave?

Re:It's not that big of deal

[Nutria]

But fp is, by nature, slightly imprecise. Really, Really Small numbers would get lost in the noise.

Re:It's not that big of deal

[orkysoft]

No, they don't. Read the article posted earlier today for more information.

Re:It's not that big of deal

[Flavio]

You can always use the c interface (which itself is weird, considering matlab's roots in fortran...)

The reason the C interface is weird is because MATLAB stores multidimensional arrays in column-major order, like Fortran. C, on the other hand, uses row-major order. However, if you work with linear algebra, then you'll appreciate the column-major layout, because it coincides with the order returned by the vec operator (which is used all the time in computational linear algebra, and stacks the columns of a matrix).

but then you'd have to learn c. Matlab is a tool for physicists and engineers, not computer scientists. They don't necessarily want to take the time to learn c, or they'd have done that. Some do, anyway, of course, but usually what they produce will be one off functions for a specific goal, not entire libraries suitable for sharing.

I work with digital signal processing and use MATLAB almost on a daily basis. The reason DSP engineers use MATLAB is not because they don't know or don't want to know C. In fact, a good DSP engineer must be very competent at writing clear and efficient C code, because that's what he needs to actually implement algorithms on hardware. Modern high performance DSPs are so complex that coding things in assembly is completely out of the question.

The reason MATLAB is so valuable is that it allows one to prototype things extremely fast with minimal performance loss (if you know what you're doing). Of course you won't have a MATLAB environment running on a DSP, so you'll eventually have to write the C code. But since most of my time is spent developing algorithms instead of actually implementing them, MATLAB lets me be much more productive.

Re:It's not that big of deal

[644bd346996]

64-bit computing isn't about having 64-bit ints. It's about having 64-bit pointers.

Re:It's not that big of deal

[_merlin]

You don't even have to write C when you want to get it on your DSP - MATLAB Real-Time Workshop can generate the C code for many popular DSPs.

Re:It's not that big of deal

[Mr Z]

The reason you need the decimal datatype is not because "small numbers get lost in the noise." It's because paper-driven accounting was always done in decimal, and so to keep the numbers matching, the computer needs to round in the same way someone doing it on pencil and paper would do it. It's about compatible rounding and representation, not the size of "ulp" (Units of the Last Place) on any given calculation. A 32-bit decimal float is less precise and has less dynamic range than a 32-bit binary float. But, arithmetic with the decimal float will match the hand arithmetic and the binary one won't, since the inputs come pre-rounded to convenient boundaries in the base-10 world.

Anyway, small numbers do get lost in the noise with floating point if you ever add or subtract them from large numbers.

Re:It's not that big of deal

[Hognoxious]

The relative precision is the same over all numbers, because the mantissa is a fixed size. The bits that fall off it might represent billions or billionths, but that depends on the exponent and so the same scaling factor applies to the number and the error.

Re:It's not that big of deal

[tepples]

You don't even have to write C when you want to get it on your DSP

...unless you want it to be efficient. See someone else's post.

Who uses integers in MATLAB?

[dissipative_struct]

MATLAB isn't strongly typed, and by default variables are floating-point (I think 64-bit is the standard if type isn't specified). Makes sense for scientific programming. You need to go out of your way to use integer types in MATLAB, and the only reason I've ever had to do it is when trying to convert MATLAB scripts to C code to run on fixed-point processors. I do think that not supporting 64-bit integer operations is an oversight but I don't think it affects the vast majority of MATLAB users.

Re:Who uses integers in MATLAB?

[coolsnowmen]

yep, really the only reason they exist is for converting numbers for input and output, not for doing any computations in matlab with them.

Re:Who uses integers in MATLAB?

[ClickOnThis]

You need to go out of your way to use integer types in MATLAB

...and this is a good thing, when you consider that Matlab demotes float or double values to int when you mix them with ints. I was amazed when I discovered this. It's the only language I know with this evil behaviour.

There aren't may reasons you'd need integers in Matlab. Some that come to mind: (1) if you need more digits of precision than float or double offer, and you don't need the dynamic range of the exponents; (2) if you need to manipulate the data as bits; (3) if they're more computationally efficient for the problem you're solving; or (4) if want to save memory (e.g., with 16-bit ints.)

Re:Who uses integers in MATLAB?

[pjabardo]

Actually, if you you are working with very large data sets you might need to index using 64 bits. A friend of mine who knows very little programming was using matlab to compute all eigenvalues of a large operator. It was all working fine until he started to use his scripts on larger problems. At the time, a couple of years ago I had to recompile octave to use 64 bits as the default integer and the program just worked fine with the larger data-sets. The 64 bits integer was available as a configure option so I guess somebody (other than me and my friend) found this useful.

Memory moreso than computations

[dunc78]

As another Engineer that uses MATLAB quite frequently, the only reason I have used 64-bit support was to analyze larger data sets.

Re:MATLAB ~= fast

[dunc78]

Don't know what your scientific language of choice is, but I have compared MATLAB programs to FORTRAN programs and the difference in speed was negligible. A properly written MATLAB function can be quite fast.

I'm not surprised...

[Jah-Wren Ryel]

I'm not a MATLAB user, just someone who has had to troubleshoot problems with it for a variety of clients.

A while back, more than a few years now, MATLAB on HPUX was limited to about 1GB of memory. Any MATLAB code that needed more memory than that was shit out of luck - even on a 64-bit machine with 64GB of RAM. This was partly due to MATLAB only being available as a 32-bit binary for HPUX and partly due to MATLAB having been compiled and linked in the most naive way possible. After diagnosing the problem with a client's MATLAB code (they had a lab full of $2M computers and couldn't run this software that only needed a couple of GB of data), I wrote a short explanation of the compile and link flags necessary to enable any process to access at least 2GB of RAM with practically no impact and 3GB with only minimal impact. In either case, no code changes necessary whatsoever.

MATLAB's customer support group responded with a categorical denial that it was even possible to do - that HPUX architecturally limited all 32-bit processes to 1GB of addressable memory. While a customer-specific test release would have been the ideal response, I was really only expecting them to open a feature request and get the next release built the right way. But they wouldn't even give my client that (despite them having an expensive support contract) - just a flat out denial of reality instead. The solution for my client was ultimately to rewrite their software in C and link it with the right flags to get access to 3GB of memory.

So, given just how strong their disinterest was in even trying to make their software work for big boys doing scientific computing, I'm not surprised to hear that all these years later they still haven't even bothered to implement native 64-bit math. They are entrenched and there just isn't enough competition to make them lift a finger.

Re:Yes but Octave

[Anonymous Coward]

Like every other crap gnude ware (Octave) has a sucky GUI.

Hopefully, this might be fixed very soon via Google Summer of Code 2010.

http://community.kde.org/GSoC/2010/Ideas#Project:_Cantor:_Add_a_new_Backend

Especially since someone has implemented it....

[welcher]

If you really want this support, get the user contributed package from matlab central. That wasn't too hard was it?

Re:Especially since someone has implemented it....

[welcher]

The point is that very few engineers currently want or need this functionality -- if they did, the Mathworks folks would surely be on to it. The native type is defined, abstract methods are waiting there to be defined, and someone who needed it has implemented it and made it available. Incidentally, that package has had 38 downloads since july, perhaps indicating the level of demand. From this thread, it looks like the company is waiting for the demand before implementing it themselves.

Re:Especially since someone has implemented it....

[welcher]

We are talking about 64 bit integers. Matlab has 64 bit floating point arithmetic. This means you can do exact integer arithmetic up to 2^53. I'd say mathworks has a pretty good idea of the demand for 64 bit integers and it is not that great -- it's not like it is a huge job for them to implement it so they would surely do it if their customers wanted it.

Python as an alternative

[physicsphairy]

The summary mentioned Octave as an alternative to Matlab. There is also Scilab (which has some more c-like features).

In recency I have simply been using Python. Use the iPython (interactive python) shell and load scipy (from scipy import *) and you have a very nice calculating environment. The scipy arrays are quite a joy to work with compared with what I remember from Matlab. If you're working with equal size 1D arrays then they can be used without modification in normal mathematical expressions, so a lot of my code no longer involves any iteration with for loops.

There is a graphing library (pylab) based on Matlab syntax. If you start iPython with the -pylab flag it will print out plots the same way as in Matlab. There is also Easyviz which I believe also uses Matlab syntax but interfaces with a number of standard graphing programs (like Gnuplot.)

The sympy package for doing symbolic manipulations is also quite nice, IMHO.

Disclaimer: I only used Matlab casually for my undergraduate math classes.

Numeric Python

[Efreet]

Just another reason to switch to numeric python. The more I use Matlab the less I find that I like it.

Re:Numeric Python

[Kensai7]

With NumPy and SciPy, it is just as easy to do what MATLab does in a language that's actually fun to work with.

I just hope Sage succeeds and becomes more well-known. It's the best open alternative we have.

Re:Numeric Python

[Kensai7]

This is ridiculous. Why flamebait?!

Sage is a free open-source mathematics software system licensed under the GPL. It combines the power of many existing open-source packages into a common Python-based interface. Mission: Creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.

Re:Yes but Octave

[ceoyoyo]

So it clones Matlab very well then.

Re:Yes but Octave

[Vyse of Arcadia]

3D data is all but ungraphable on Linux systems anyway, so I suppose Octave is not alone here.

As I recall, MATLAB has a Linux port. As does Maple, Mathematica, et cetera. And Mayavi is an open source program capable of excellent 3D graphics that works with Python, and therefore SciPy.

So what you really mean is that 3D data graphing is inadequate with Octave and gnuplot on any system. 3D data is perfectly graphable in Linux.

A view from Octave developer

[highegg]

Being the guy who implemented the proper 64-bit arithmetics support in Octave 3.2, I can maybe share some interesting points. Matlab's design choice of double as the default type is both a blessing and a curse. Usually the blessing strikes you first (I always disliked it that 1/2 is 0 in C++ and Python, finally Python 3 changed that as well), but you start to feel the curse when diving deeper, and integer arithmetics (which I agree is far less used than floating point) is a perfect example. Initially, Matlab probably had no integers. Given that double is the default, Matlab creators decided to make the integers "intrusive", in the sense that integers combined with reals result in integers, not reals, contrary to most other languages. The motivation is probably so that you can write things like a + 1 or 2*a without a silent conversion. Hence, when I is integer, D is double and OP is any operator, I OP D behaves like int (double (I) OP D). Except that things like a + 1 seem to be optimized (something Octave currently lacks, but it shouldn't be hard to do). int64 is where things start to get messy, because not all 64-bit integers can be exactly represented in double. So, using the simple formula above, 0.5 * i64 could occassionally do something else that i64 / 2, which is highly undesirable. In order to do the "right thing", Octave will choose one of two options: first, if it discovers that "long double" is at least 80-bits wide (so that it can hold any 64-bit integers), it will use that to do the operations. If not, it will employ a custom code to emulate the operation as if it was performed with enough precision. It's based on manipulating the mantissa and exponent of the double and is much slower. Although it was kinda fun to implement it, it is really a lot of work for too little music, so that can partially explain MathWorks' attitude to this. Unlike Octave, MathWorks doesn't really need to aim at source portability (as they just distribute binaries), so maybe they're just waiting for proper long double support in all compilers they use, and then they will just use the simple approach. Or maybe they're waiting for some important future design change. When I implemented this, I was fully aware that it's not a killer feature, yet I thought it may make Octave more interesting to some Matlab users. So I'm glad someone noticed :) In any case, I suppose at some point Matlab will support this as well.

Dynamic typing

[janwedekind]

Myself I am developing HornetsEye which is a Ruby-extension for doing computer vision.
The problem with supporting various types is that you end up with a lot of possible combinations when doing computations. I.e. say if you want to support arrays of 8-, 16-, 32-, and 64-bit integers (signed and unsigned) as well as 32-bit and 64-bit floating point, you have 10 ** 2 possible combinations of types when element-wise adding two arrays.
If speed is not an issue however, you could just use Ruby's dynamic typing. Ruby's integer classes use dynamic typing in their computations in order to avoid numeric overflow:

( 10 ** 2 ).class
# Fixnum
( 10 ** 10 ).class
# Bignum

Also you can seamlessly combine rational numbers, big numbers, complex numbers, and matrices in a seamless way which is really neat:

require 'mathn'
2/4
# 1/2
( Complex::I / 2 ) ** 3
# Complex(0, -1/8)
1 / 2 + Complex::I / 3
# Complex(1/2, 1/3)
( 1 / 2 + Complex::I / 3 ) ** 5
# Complex(-199/2592, 61/3888)
( 1 / 2 + Complex::I / 3 ) ** 24
# Complex(584824319281/4738381338321616896, 161741277005/32905425960566784)
a = Matrix[ [ 2 / 3, 3 / 4 ], [ 4 / 5, 5 / 6 ] ]
# Matrix[[2/3, 3/4], [4/5, 5/6]]
b = a.inv
# Matrix[[-75/4, 135/8], [18, -15]]
a * b
# Matrix[[1, 0], [0, 1]]