MATLAB Can't Manipulate 64-Bit Integers 334
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.
It's not that big of deal (Score:2, Informative)
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 (Score:4, Informative)
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.
Who uses integers in MATLAB? (Score:5, Informative)
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:It's not that big of deal (Score:4, Informative)
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 (Score:3, Informative)
Re:It's not that big of deal (Score:3, Informative)
But fp is, by nature, slightly imprecise. Really, Really Small numbers would get lost in the noise.
Memory moreso than computations (Score:4, Informative)
Re:MATLAB ~= fast (Score:4, Informative)
Re:It's not that big of deal (Score:2, Informative)
No, they don't. Read the article posted earlier today for more information.
Re:MATLAB ~= fast (Score:1, Informative)
When is the last time you've used it? I noticed it has improved over the last few iterations. It precompiles a lot of stuff now, so like FORTRAN of yore, it can do better machine optimization that even a good C compiler can do since it can make better inferences about data types, preallocation, short-circuting of decisions, etc.
But of course, it'll never run real-time or be as efficient as purpose-written code (where you don't need to schlep an interpreter and all that junk along). The Mathworks will happily sell you the automatic code generation from Simulink modules, (for a significant fraction of your yearly salary, AFAIK) those will then run real-time on some CPUs - but I have no idea how good the code generated is.
So yeah. We use Matlab cause you can implement complex algorithms in hours, and visualize the data. If you want to write a pretty app with a GUI, you're using the wrong tool.
And yes, the lack of 64-bit int operations is a non-issue. Wasn't there an article about the old "what every programmer should know about floating point" paper here on /.? Unless you know the issues involved there, you won't understand the issues here.
I'm not surprised... (Score:5, Informative)
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 (Score:2, Informative)
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.... (Score:5, Informative)
Re:Who uses integers in MATLAB? (Score:3, Informative)
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:Python's SciPy and NumPy FTW (Score:1, Informative)
This is not true, in my experience. Both MATLAB and Python (numpy/scipy) use the same underlying math libraries. MATLAB often optimized for windows PCs, but numpy/scipy offer the option to optimize for your C64, or whatever, with libraries like ATLAS.
Plotting (using matplitlib) is also faster, as the backend is separated from the plotting engine.
Finally, if something is slow, it is much easier to wrap lower level languages such as C or FORTRAN in python, using a number of different packages (SWIG, ctypes, cython, f2py, weave, etc...)
Python as an alternative (Score:5, Informative)
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 (Score:5, Informative)
Just another reason to switch to numeric python [sourceforge.net]. The more I use Matlab the less I find that I like it.
Re:It's not that big of deal (Score:5, Informative)
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 (Score:2, Informative)
64-bit computing isn't about having 64-bit ints. It's about having 64-bit pointers.
Re:Yes but Octave (Score:5, Informative)
So it clones Matlab very well then.
Re:Who uses integers in MATLAB? (Score:3, Informative)
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:Yes but Octave (Score:5, Informative)
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 [wikipedia.org] 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.
Re:64 bit integer plus 64 bit integer equals 65 bi (Score:1, Informative)
I'm hoping that is a joke
Joke or not, it's reality for anyone dealing with fixed point math. You have to go through your entire algorithm and decide which bits are worth keeping and how many you need. Things like Hamming windows don't like it when an accumulator overflows.
So you have to figure out how many numbers you're adding, take ceil(log2(N)) of that, and that's how many extra bits you need, or more to the point, how many high bits that the input data can't use. If N gets really big, that can cut way into a 32-bit integer. Trying to drop least-significant bits at various points in the vector raises your noise floor, decreasing your SNR (the noise looks like regularly-spaced impulses, too, which can hurt a clock-recovery algorithm). Also, this bit-eating effect cascades.
Multiplication is even worse: you get as many bits out as the sum of the bit counts in; 32x32 => 64.
As for Matlab... so what. Seriously. Matlab went for a very long time supporting only double precision floats (heck, it went a long time only supporting 2-D matrices). Other types were only supported in I/O; they got converted to doubles internally. They added 8-bit integers to make the video processing people happy back in the days of 3dfx. Then they added floats because some people wanted to trade precision for storage space, and integers because the fixed-point simulation stuff was getting hard to do. It's really a case study of a 90% solution.
For 18 years, I've worked at a research lab that swears by Matlab. (Though their recent licensing costs have us moving a lot of stuff to Python, and we tried Octave but dumped it because we couldn't migrate to it because they were missing key features that they didn't believe they needed. Our sponsors don't pay us to drop everything to learn Octave's internals, write patches to support what we need, and fight Octave politics to get those patches in.) And in all that time, the number of times I've seen anyone use integer arithmetic... is zero.
The vastly larger dynamic range, and logarithmic scaling, of double-precision floating point worked just peachy. Slow and memory hogging at times, to be sure. But we could crank out test algorithms in Matlab far faster than C++. Now... Python, NumPy, matplotlib... we're slowly moving over.
Python is a far more serious language than Matlab. Matlab is a hacking language like BASIC. It's lousy to manage a big project with. Seriously, one file equals one function? A class is a directory starting with an @? And there's no way to do select(), so we can't hook it up to our TCP/IP sockets and serial ports at the same time? And we're paying how much?
If you're serious, develop your algorithm in Python. 90% of the time, it'll be fast enough; the other times, you were going to have to write it in C or C++ anyway, and if you wrote your code in Python, your code will be far closer to C or C++ than if you wrote in Matlab. You'll never worry about licensing. Forget Octave and Matlab. And don't get me started on Matlab-to-C compiler. (Short version: if your program is read-compute-write-terminate, it might work for you. If it's event driven, forget it.)
Re:It's not that big of deal (Score:3, Informative)
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:Especially since someone has implemented it.... (Score:5, Informative)
Re:Yes but Octave (Score:1, Informative)
3D data not graphable on linux. Are you kidding? Try Visit from LLNL, freeware and enables
analysis of multi-terabyte datasets on either single or multi-core systems. Other options exist,
such as Paraview or Mayavi2, both of which are free. All of these offer python scriptable
interfaces. In fact, I'd be wonder why anybody would want to use any kind of commercial
software, or anything related to Octave for data analysis today.
Re:It's not that big of deal (Score:1, Informative)
No, Octave is not comparable to Matlab unless all you do is basic operations. Is there a real-time workshop, Simulink, all the toolkits, etc. for Octave?
Re:It's not that big of deal (Score:3, Informative)
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:Especially since someone has implemented it.... (Score:5, Informative)
A view from Octave developer (Score:5, Informative)
Re:Numeric Python (Score:4, Informative)
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 (Score:3, Informative)
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:It's not that big of deal (Score:3, Informative)
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.
Dynamic typing (Score:3, Informative)
Myself I am developing HornetsEye [demon.co.uk] 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]]
Re:Yes but Octave (Score:1, Informative)
> 3D data is all but ungraphable on Linux systems anyway,
? eh, you must be looking very hard in the wrong place.
for one, try Paraview [paraview.org]. ... (including my favorite)
for two, try VisIt [llnl.gov].
for three, there are many more like that
Re:It's not that big of deal (Score:4, Informative)
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 [slashdot.org].
Re:Who uses integers in MATLAB? (Score:3, Informative)