Slashdot Mirror
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.
How is this news?
Yes it is. People who do the kind of hardcore math that MATLAB is good at are the ones who actually need 64 bit computing.
Yes it is. People who do the kind of hardcore math that MATLAB is good at are the ones who actually need 64 bit computing.
Surprisingly, not all that often. People who work with very sensitive systems (chaotic one in particular) or VERY precise data need 64 bit precision, but for 98% of everyone else, it's just not necessary. Anyone doing really advanced work is going to use a supercomputer, for obvious reasons.
MATLAB's largest audience is engineers, although applied mathematicians and physicists use it often, just not nearly in equal numbers with engineers (who also outnumber the others greatly). Given that engineers work with real data, which never has more than 6 digits of accuracy anyway (3 is more realistic), the push for higher precision just isn't there.
It's one reason MATLAB doesn't have the greatest 64-bit support: there's no real demand for it, yet. The few who need it can just as easily work in C++, since all MATLAB really is is a collection of routines with a nice interface, much easier plotting/graphic commands, and a nice set of help files.
For reference, I've had 64 bit computing readily available to me for...my entire career, and I've never once NEEDED it, despite being an applied mathematician.
As someone who uses math quite a lot in academia, I can tell you that I've never noticed the missing operators. I just don't use 64-bit integers. The reason *I* upgraded to 64-bit Matlab is because I kept running up against memory constraints. 64-bit Matlab can allocate much larger arrays. I am sure there are places where it would be convenient to use really big integers but I find it hard to believe that this is really a big headache for anyone; the main improvement with the 64-bit version is a much bigger memory space.
If you're a physicist using MATLAB, then you are (a) using floating point arithmetic, not huge integers and (b) more likely to be using Mathematica than MATLAB in the first place. Huge integers are more useful in computer science, doing encryption and data processing and such, than in physical simulations. Says the EE/Physics guy with no background in CS.
MATLAB does most everything with doubles, int and float formats are really only there when dealing with input/output to files. If i put A = 1 into a command line, its put in memory as a double. I use MATLAB most of my working day for signal processing algorithim design, and I don't think I've ever needed the precision of a 64 bit integer. Numbers bigger than a 32 bit integer can handle pop up from time to time, but never with more precision than a double provides.
Well, having to go dig an additional library to add native types is a bit paradoxal isn't it ? Even more when the software cost a lot of money and is directed at engineers.
EULA : By reading the above message, you agree that I now own your soul.
For a program like octave, having no GUI is very forgiveable. There is really no way to work with the system outside of prompt commands. Even Matlab is very prompt based.
What is unforgivable in Octave's case is its graphing capabilities. Octave used Gnuplot for drawing which basically means it is stuck in the 1990s when it comes to making plots. 3D plots are slow, difficult and complicated things to create. Animations are out of the question. 99% of the time, you're better off exporting to png (itself a nighmare), and animating from those. 3D data is all but ungraphable on Linux systems anyway, so I suppose Octave is not alone here.
May the Maths Be with you!
Umm, you realize you can do math on greater than 32 bits values in Matlab, just not using the 64-bit platforms's ability to natively handle 64 bit datatypes. After all, I can do make on 64-bit values on an 8-bit micro-controller just fine, it will just take more than a few instructions.
And as stated before, this matters little as it is a performance issue, and matlab still offers the best performance of its class, even vs. those who do have this feature.
Hmm, a double has 64 bits, where do the last 12 go?
A 64 bit integer will lose precision when converted to a 64 bit double because the double has to use some of the bits for the exponent and the rest go the mantissa. If 12 bits go to the exponent, then your 64 bit integer now has to be expressed as a 52 bit integer, raised to some power. There are (I think) 2^11 distinct numbers that would have the same representation as a double.
using 64-bit integers instead of floats is a common trick in embedded C for control and signal processing on low power processors. I have experience of four different embedded systems used in commercial products from three different companies I've worked with - three of the four used 64-bit integers for roundoff-sensitive calculations.
I was a bit surprised that Matlab can't handle this, but then I've seen the poor quality of the ostensibly production-ready code that comes out of their M2C converter - it was about ten times the code footprint and a fifth the speed of a minimally-optimised C version of the same algorithm.
Honestly, I don't know how anyone can justify paying for this, when R (and even Octave in this instance) is more capable. Where the target platform requires C or asm code, then doing development in Matlab is usually more trouble than it saves. The graphs are prettier, though.
1998 called. It wants to know why you havent learned anything since then.
"His name was James Damore."
CPU operations are limited to a certain number of bits for their operations. Programming languages like C/C++ perform their basic arithmetic operations at the machine level, so they inherit the same limitations. These bounds are not a limit either through library/template facilities at the C/C++ level, or with basic operations in high level (particular object oriented) languages such as Pike and Python.
I can tell you libgmp is not stuck with bcd. But the bcd aspect will exist because some kinds of uses for extended precision are financial/money based, and conversion to and from an external decimal format is sufficiently frequent that it's easier/faster to just do the arithmetic directly on decimal, even if tightly squeezed into 4 bits per digit. This has been going on since early computers. FYI, the ancient IBM model 1620 computer could do this in hardware. As you can see from the code in the links I posted earlier, a choice of language can hide the fact that the underlying architecture has fixed width arithmetic.
BTW, for fun, compare the speeds of those two programs, which are implementations of the same algorithm.
now we need to go OSS in diesel cars