Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

MATLAB Can't Manipulate 64-Bit Integers

kdawson posted more than 4 years ago | from the does-not-compute dept.

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

cancel ×

334 comments

Sorry! There are no comments related to the filter you selected.

So... (5, Insightful)

Anonymous Coward | more than 4 years ago | (#32067898)

How is this news?

Re:So... (1)

DarkKnightRadick (268025) | more than 4 years ago | (#32067916)

It's news for nerds?

Exactly, 64 bits is so over rated (0)

Anonymous Coward | more than 4 years ago | (#32068174)

I mean, it's only double the size of 32 bits, so who cares? It's not like it's 4 billion times more, so, exactly - SO ?

Especially since someone has implemented it.... (5, Informative)

welcher (850511) | more than 4 years ago | (#32068248)

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

Re:Especially since someone has implemented it.... (5, Insightful)

ProfMobius (1313701) | more than 4 years ago | (#32068306)

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.

Yes but Octave (-1, Troll)

Anonymous Coward | more than 4 years ago | (#32067904)

Like every other crap gnude ware has a sucky GUI.

Re:Yes but Octave (1)

Mitchell314 (1576581) | more than 4 years ago | (#32067932)

You mean a TUI? There's more to it than pretty windows.

Re:Yes but Octave (2, Informative)

Anonymous Coward | more than 4 years ago | (#32068246)

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

Re:Yes but Octave (5, Insightful)

ObsessiveMathsFreak (773371) | more than 4 years ago | (#32068466)

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.

Negative Slashvertisment? (2, Funny)

XPeter (1429763) | more than 4 years ago | (#32067910)

Am I missing something here?

Re:Negative Slashvertisment? (1)

bkpark (1253468) | more than 4 years ago | (#32068004)

No, it is a Slashvertisment, just for GNU Octave, rather than MATLAB.

Answer (2, Insightful)

girlintraining (1395911) | more than 4 years ago | (#32067918)

What is the point of having numerical data types that can't be manipulated?

So they can charge more for the upgrade?

In other news... (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32067930)

Ubuntu still can't recognize my wireless card... can I submit a story about?

Re:In other news... (0)

Anonymous Coward | more than 4 years ago | (#32067966)

Only if Steve Jobs hit it with a hammer until it was nonfunctional.

Hmm... (0, Offtopic)

gbutler69 (910166) | more than 4 years ago | (#32068176)

Maybe you should buy decent hardware, or, I don't know, read the FAQ and instructions for dealing with lame-ass Broadcom Cards (like I had to do today to fix my Mother-in-Laws lame-ass HP Pavilion dv6000).

Re:In other news... (0)

Anonymous Coward | more than 4 years ago | (#32068190)

Windows still won't read my wireless card. Granted the company does not make windows drivers, but I still think it is windows fault.

Re:In other news... (0, Offtopic)

GNUALMAFUERTE (697061) | more than 4 years ago | (#32068498)

And that is Ubuntu's fault how exactly?

It is the manufacturer's duty to develop drivers for your platform. Off course, some kernel developers are nice enough to develop drivers when the companies fail to do so. In that case, the company is still at fault, and there is no way you can blame Ubuntu or the kernel developers for that lack of hardware support. Now that I think of it, you can't blame the company either. They develop their hardware and they have no obligation to provide support to any platform. it is your fault for buying shitty, unfriendly hardware with no GNU/Linux support. Right now, almost all hardware is supported out of the box on GNU/Linux, but even when it wasn't, I didn't have any kind of issues with it, because I check before I buy.

what about (0)

Anonymous Coward | more than 4 years ago | (#32067936)

maple 13?

It's not that big of deal (2, Informative)

Anonymous Coward | more than 4 years ago | (#32067958)

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 (3, Informative)

wizardforce (1005805) | more than 4 years ago | (#32067994)

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 (5, Insightful)

robot256 (1635039) | more than 4 years ago | (#32068086)

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.

Re:It's not that big of deal (3, Informative)

Jeffrey Baker (6191) | more than 4 years ago | (#32068106)

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 (1)

gumbi west (610122) | more than 4 years ago | (#32068538)

I don't understand. Why doesn't your RDBMS take care of that?

Alternately, couldn't you just split it in two columns and merge on A and B instead of just A?

For the record, IAAS

Re:It's not that big of deal (2, Informative)

Nutria (679911) | more than 4 years ago | (#32068152)

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 (2, Informative)

orkysoft (93727) | more than 4 years ago | (#32068206)

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

Re:It's not that big of deal (1, Interesting)

Anonymous Coward | more than 4 years ago | (#32068198)

Or they could be using it for signal processing and modeling. And yes I have seen it used for that.

Says the EE guy

Re:It's not that big of deal (0)

Anonymous Coward | more than 4 years ago | (#32068460)

If you're a physicist using MATLAB, then you are... more likely to be using Mathematica than MATLAB in the first place.

On the principle that if you are using MATLAB it's certain that you're using MATLAB, doesn't that entail a greater than 100% probability that you're using Mathematica?

Re:It's not that big of deal (2, Interesting)

forand (530402) | more than 4 years ago | (#32068512)

Except when it comes to packing more data into a limited bandwidth data stream. It is often the case that bit information is encoded into large integers then unpacked when analysis/reconstruction is done for instruments where data bandwidths are limited (e.g. the South Pole and satellite missions). That said most groups working in those environments do not use MATLAB.

Re:It's not that big of deal (2, Insightful)

martin-boundary (547041) | more than 4 years ago | (#32068130)

Huh? How did physicists manage before the era of 64 bit computing, then?

This is ridiculous, the first thing any self respecting physicist will do is change the units of the problem.

Re:It's not that big of deal (4, Insightful)

KibibyteBrain (1455987) | more than 4 years ago | (#32068558)

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.

Re:It's not that big of deal (3, Insightful)

seeker_1us (1203072) | more than 4 years ago | (#32067996)

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.

Re:It's not that big of deal (1)

blai (1380673) | more than 4 years ago | (#32068024)

Suppose one of the hardcore people you're talking about can code up a 64-bit arithmetic library that overloads existing arithmetic functions, then share said library with the rest of us?

Re:It's not that big of deal (3, Interesting)

zippthorne (748122) | more than 4 years ago | (#32068076)

Seems like a lot of effort. You can always use the c interface (which itself is weird, considering matlab's roots in fortran...) 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.

Frankly, even equally worrisome is that Matlab doesn't appear to take advantage of GPGPU yet. The concept has been around for over half a decade, and I'd have expected the MAtrix LABoratory to jump on the bandwagon quicker than most. It's a game changer in their core competency, after all.

Re:It's not that big of deal (2, Insightful)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32068262)

Frankly, even equally worrisome is that Matlab doesn't appear to take advantage of GPGPU yet. The concept has been around for over half a decade, and I'd have expected the MAtrix LABoratory to jump on the bandwagon quicker than most. It's a game changer in their core competency, after all.

I haven't looked at MATLAB+GPGPU recently, but back in the olden days before CUDA and OpenCL there were a handful of 3rd party matlab extensions that made use of GPGPU. Nothing official, but still plenty functional in their limited areas of implementation. The company's laziness with respect to GPGPU is no surprise (see my other rant in this story's discussion) and the fact that others have put together limited GPU-based extensions has probably further reduced the pressure for them to do anything in that area.

Re:It's not that big of deal (1)

Rufus211 (221883) | more than 4 years ago | (#32068382)

Frankly, even equally worrisome is that Matlab doesn't appear to take advantage of GPGPU yet. The concept has been around for over half a decade, and I'd have expected the MAtrix LABoratory to jump on the bandwagon quicker than most. It's a game changer in their core competency, after all.

I guess it depends on the exact question you're asking. A google search for "matlab gpgpu" shows that there are lots of ways to take advantage of GPGPU (NVidia's CUDA specifically) from within Matlab.
MATLAB plug-in for CUDA [nvidia.com]
AccelerEyes [accelereyes.com]
GPUmat [gp-you.org]

However AFAIK there's no plan for native support of GPGPU within Matlab. It's kind of ridiculous that there's not considering the 10x speedup frequently reported by using the above tools.

Re:It's not that big of deal (5, Informative)

Flavio (12072) | more than 4 years ago | (#32068436)

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 (2, Informative)

spikenerd (642677) | more than 4 years ago | (#32068124)

You mean like Octave [gnu.org] ?

Re:It's not that big of deal (3, Insightful)

Anonymous Coward | more than 4 years ago | (#32068054)

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.

Memory moreso than computations (3, Informative)

dunc78 (583090) | more than 4 years ago | (#32068158)

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

Re:It's not that big of deal (2, Insightful)

nedlohs (1335013) | more than 4 years ago | (#32068160)

1. MATLAB doesn't support 64 bit ints
2. People still us MATLAB.

Thus, there is a group of people "who do the kind of hardcore math that MATLAB is good at" who don't need 64 bit computing.

Re:It's not that big of deal (2, Informative)

644bd346996 (1012333) | more than 4 years ago | (#32068484)

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 (0)

Daniel Dvorkin (106857) | more than 4 years ago | (#32068030)

The purpose of establishing an int64 data type is to allow direct manipulation, without resort to such hackery, of integers which are larger than 32 bits but smaller than 64 bits. You may have noticed that there are lot of such integers ... very nearly 2^64 of them, in fact.

If MATLAB is optimized for 32-bit integer arithmetic, then maybe it's time to change that?

By your logic, we wouldn't need any integer type longer than 2 bits. You could certainly design an integer arithmetic scheme on that basis, but I doubt you'd want to.

Re:It's not that big of deal (1)

Trepidity (597) | more than 4 years ago | (#32068116)

By your logic, we wouldn't need any integer type longer than 2 bits. You could certainly design an integer arithmetic scheme on that basis, but I doubt you'd want to.

I think the argument is more that, in practice, 32 bits is a decent sweet spot for the changeover from native ints to arbitrary-precision bigints (whereas 2 bits is not a sweet spot). Are there that many cases where someone needs integers between 32 and 64 bits, but doesn't need to account for the possibility of >64-bit integers, and therefore doesn't need to use routines that can handle arbitrary-size integers? If there were a lot of such cases, changing from 32- to 64-bit as the switchover point from native to bigint arithmetic would be justified. But the guess is that those cases aren't common, at least among matlab users.

Re:It's not that big of deal (2, Insightful)

Supergibbs (786716) | more than 4 years ago | (#32068544)

Sweet spot? Could it have been that a majority of computers were 32-bit? Ya sure, 64 bit computing has been around a while but it was mostly specialized servers. Now that most new computers are x64 [wikipedia.org] compatible it would make sense to optimize for 64-bit. The many integers between 32 and 64 bits would be processed much faster and couldn't the bigint routines take advantage as well? I am not sure how big int work other than they use strings for storage. I assume they use clever math to break the calculations up and then piece it back together, so could 64bit reduce the number of calculations?

Re:It's not that big of deal (0)

Anonymous Coward | more than 4 years ago | (#32068036)

What is to be gained by rewriting everything for 64 bit?

Supporting arithmetic on 64-bit numeric types doesn't require "rewriting everything" (unless the code is really really really badly structured).

Re:It's not that big of deal (2, Insightful)

coolsnowmen (695297) | more than 4 years ago | (#32068118)

numerical computations that are highly optimized for speed on computers do not always allow for variable sized numbers. The more you assume about a problem, the faster you can make the algorithm to solve it. I'm betting that there are many optimized numerical algorithms in matlab that use underlying knowledge of the data structure itself to solve it. It is a trade off speed vs scalability/generality.

big arrays (0)

Anonymous Coward | more than 4 years ago | (#32068362)

You need 64 bit integers for holding indexes into arrays with more than 2 billion elements.

Python's SciPy and NumPy FTW (1)

WeatherGod (1726770) | more than 4 years ago | (#32068032)

Another useful alternative is to use SciPy and NumPy packages for Python. Python doesn't have any issues with dealing with long numericals.

Re:Python's SciPy and NumPy FTW (2, Insightful)

Daniel Dvorkin (106857) | more than 4 years ago | (#32068066)

SciPy/NumPy, R, and Octave are all perfectly good alternatives to MATLAB these days for most work. But there are a lot of people who rely on MATLAB-specific toolboxes. I look forward to the day when proprietary math and stats packages take their place in the bitbucket of computing history, but we're not quite there yet.

Re:Python's SciPy and NumPy FTW (1)

gardyloo (512791) | more than 4 years ago | (#32068128)

MATLAB is often very much faster than SciPy/NumPy at the moment, but the latter programs are very much more capable (and, the vast majority of the time, free). My colleagues use MATLAB; I'm perfectly happy producing better results in Python.

Re:Python's SciPy and NumPy FTW (1, Informative)

Anonymous Coward | more than 4 years ago | (#32068324)

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

Re:Python's SciPy and NumPy FTW (1)

WeatherGod (1726770) | more than 4 years ago | (#32068254)

Amen to that... except the part about R. It and its bastard proprietary brother S+ can also go to the bitbucket as far as I am concerned.

I am sorry, did my bitterness just come through there?

Re:Python's SciPy and NumPy FTW (1)

Daniel Dvorkin (106857) | more than 4 years ago | (#32068352)

Heh, to each his own, I guess. I mostly work in R these days, and while I admit it's quirky, once you get used to its quirks it's quite a useful langauge. Overall, I'd rather be programming in Python than just about anything else, but in my lines of work (bioinformatics and biostatistics) R provides the best overall combination of features and usability. YMMV, and obviously does in this particular case.

Re:Python's SciPy and NumPy FTW (2)

WeatherGod (1726770) | more than 4 years ago | (#32068434)

What I find odd about R/S/S+ was that the ones who tended to learn it better were the begineers who never programed in another language or had limited exposure. People like me who have been exposed to many mainstream languages find it frustrating.

The professor who taught the course where I had to use S+ told me something along the lines: "It is a language designed by statisticians, of course it will behave randomly!"

Re:Python's SciPy and NumPy FTW (1)

elashish14 (1302231) | more than 4 years ago | (#32068462)

Any word on how they compare for speed? I'd be surprised if Python's speeds are remotely comparable to those of Matlab, which is after all, optimized for numeric calculations.

The R program can't do 64 either (0, Flamebait)

Jeffrey Baker (6191) | more than 4 years ago | (#32068050)

FWIW, GNU R, the freetard knockoff of S, also can't do anything with 64-bit numbers. It stores them in a double, which gives you 52 bits of exact integers and beyond that it's approximate. This can really bite you in the ass if you aren't aware of it ... and it's not documented anywhere except in code. It can be especially bad if you try to read a BIGINT (64-bit integer) value via RODBC, which silently truncates the value to 52 bits.

Re:The R program can't do 64 either (1)

Daniel Dvorkin (106857) | more than 4 years ago | (#32068112)

R is not a "knockoff of S". It is a free implementation of the S language. S-Plus is a proprietary implementation of that language. Maybe you should read up on the history.

And ... "freetard"? WTF? If you're identifying this is a F/OSS problem, what's MathWorks' excuse?

Re:The R program can't do 64 either (-1, Flamebait)

Jeffrey Baker (6191) | more than 4 years ago | (#32068192)

A freetard is an uncompromising advocate of the FSF philosophy. R is a FSF project and is therefore by definition a freetard product. Did you have a point you wanted to make regarding R and 64-bit numbers or did you just come here to act offended?

Re:The R program can't do 64 either (1)

NNKK (218503) | more than 4 years ago | (#32068212)

Did you have a point you wanted to make about the subject at hand (*MATLAB*'s support or lack thereof for 64-bit integers), or did you just come here to be offensive?

Re:The R program can't do 64 either (0)

Jeffrey Baker (6191) | more than 4 years ago | (#32068252)

The point is that when scientists write software they store big numbers in floats because no sane person needs more precision than that. The idea of huge, exact numbers is foreign to physicists and chemists and statisticians. Especially statisticians.

Only computer programmers and cryptographers need huge, exact integers.

Re:The R program can't do 64 either (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32068354)

And chip designers. And number theory specialists (not all of them, oh the shock, are cryptographers). In fact, anyone that uses a number as an abstraction and not a physically interpreted quantity.

Re:The R program can't do 64 either (-1, Offtopic)

Daniel Dvorkin (106857) | more than 4 years ago | (#32068268)

Wow. You're one of those people who thought "open sores" was clever, aren't you?

MATLAB ~= fast (-1)

highways (1382025) | more than 4 years ago | (#32068060)

If you want raw speed, you don't code in Matlab. Simple.

Or code a MEX function.

In short, if you're relying on Matlab to do stuff fast, you're doing it wrong.

(Fast in this context, execution time. Fast in terms of algorithm development is another story)

Re:MATLAB ~= fast (3, Informative)

dunc78 (583090) | more than 4 years ago | (#32068180)

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.

Re:MATLAB ~= fast (2, Insightful)

Brett Buck (811747) | more than 4 years ago | (#32068328)

Only if it can be vectorized. Otherwise, MATLAB is *bog slow*. Compiling as a MEX function will restore the speed.

Re:MATLAB ~= fast (1, Informative)

Anonymous Coward | more than 4 years ago | (#32068224)

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.

A Heavy User's Opinion (5, Insightful)

TerribleNews (1195393) | more than 4 years ago | (#32068068)

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.

Re:A Heavy User's Opinion (2, Insightful)

WeatherGod (1726770) | more than 4 years ago | (#32068364)

That is one of the things that pushed me away from Matlab. I kept on running into memory bounds whenever I tried to do things "the Matlab way" (i.e., no loops, vectorize, etc.). It seems that Matlab liked to copy my arrays all the time when I was going in and out of functions. It seems ridiculous to me that I would have to do things "the bad way" in order to get my work done.

#TODO: (1)

lawpoop (604919) | more than 4 years ago | (#32068072)

#TODO: finish up all operations for 64-bit integers.

Who uses integers in MATLAB? (5, Informative)

dissipative_struct (312023) | more than 4 years ago | (#32068074)

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? (2, Informative)

coolsnowmen (695297) | more than 4 years ago | (#32068250)

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

N bits ought to be enough for anybody, where N=32 (1)

davidwr (791652) | more than 4 years ago | (#32068138)

Obligatory.

Not that big a deal (3, Insightful)

usul294 (1163169) | more than 4 years ago | (#32068146)

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.

Re:Not that big a deal (0)

Anonymous Coward | more than 4 years ago | (#32068282)

Yea, this is not news. Another kdawson foot-in-mouth posting, lowering the level of intellectual discourse here.

I've been using MATLAB extensively for about 15 years now, since working on my PhD dissertation. Non-doubles are really only useful when (a) importing data from other sources where they are specified in non-double format or (b) saving data to disk where the values are limited resolution and space is an issue.

use the mex api (1)

siliconwafer (446697) | more than 4 years ago | (#32068148)

Using the MEX API it is possible to implement operators for 64 bit integers in MATLAB. They aren't provided by default but implementing your own is quite trivial.

Re:use the mex api (1)

coolsnowmen (695297) | more than 4 years ago | (#32068242)

I had no idea you could overload operators in matlab until I looked it up (thanks to you). I used to consider myself a matlab guru...now I know I am.

Re:use the mex api (1)

msuarezalvarez (667058) | more than 4 years ago | (#32068370)

gurus already knew that, you know...

Commercial software lags... (1, Interesting)

straponego (521991) | more than 4 years ago | (#32068150)

For some reason commercial software usually seems to lag worst on the 64 bit transition. Windows and OSX lagged Linux, Java and Flash were the last bits on my Linux systems to go 64 bit, etc. They act as if 64 bit is a fad, and people will soon come to their senses and revert to 32.

Re:Commercial software lags... (1)

larkost (79011) | more than 4 years ago | (#32068348)

Ya, immagine that, they acted like it actually took work and thinking to completely go through a 15+ year-old architecture and make sure that every layer is 64-bit clean. And they actually though that some of their developer time should go to improving areas of their OS's that actually matter for 95%+ of their audiences first...

With the excepton of Intel's x86 instruction set hobbling their processors, and Windows only recognizing 3GiB of RAM (then subtract the address space for your video memory), or most Intel Macs only recogising 4 GiB (also subtracting video memory, but this is a hardware limitation), 64bit OSs have been a non-event for most consumers.

People are not going to revert, but we have just come to the point now that most computers ship with enough memory that 64bit addressing even makes any difference system-wide.

Re:Commercial software lags... (1)

imikedaman (1268650) | more than 4 years ago | (#32068388)

Hate to break it to you, but Java and Flash taking so long to go 64-bit on Linux has less to do with them being commercial software and more to do with the relative irrelevance of the OS. Also, MATLAB beat GNU Octave to a 64-bit version by 18 months.

Re:Commercial software lags... (1)

yuhong (1378501) | more than 4 years ago | (#32068560)

Also, both Java and Flash have JITs, and these are not easy to port to 64-bit because all of the differences between 32-bit x86 and 64-bit x86_64 assembly/object code has to be accounted for.

Re:Commercial software lags... (0)

Anonymous Coward | more than 4 years ago | (#32068452)

For some reason commercial software usually seems to lag worst on the 64 bit transition

Commercial software, the iceberg of Itanium. It will either melt to the oblivion of obsolesce or sink an unfortunate chip of doom.

64 bit integer plus 64 bit integer equals 65 bits? (2, Funny)

LostCluster (625375) | more than 4 years ago | (#32068168)

In order for a number to need the 64th bit it must have a one in that 64th-most-significant position... and in order to add two such numbers, you end up needing a one in a 65 position... and there's your overflow error.

Re:64 bit integer plus 64 bit integer equals 65 bi (1)

coolsnowmen (695297) | more than 4 years ago | (#32068218)

I'm hoping that is a joke

Re:64 bit integer plus 64 bit integer equals 65 bi (1)

Devout_IPUite (1284636) | more than 4 years ago | (#32068338)

I think it's pretty obvious. Why use a whole 64 bits when to represent 4? You should probably just use three bits. 100. That's why machines today are so slow... All these wasted bits.

Re:64 bit integer plus 64 bit integer equals 65 bi (0)

Anonymous Coward | more than 4 years ago | (#32068438)

That's a bunch of horse shit. Doubling the number of bits you process has little to do with critical path speed. Adding extra hardware to deal with changing bit lengths in the ALU has a HUGE impact on critical path speed.

That is: the way it is is far, far faster than representing numbers in arbitrary bits.

Re:64 bit integer plus 64 bit integer equals 65 bi (0)

Anonymous Coward | more than 4 years ago | (#32068230)

Any signed 64 bit number needs the 64th bit regardless of whether it's a 0 or a 1. 0-62 just depends on the number, but 63 will always be needed.

I'm not surprised... (5, Informative)

Jah-Wren Ryel (80510) | more than 4 years ago | (#32068228)

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.

exellent competition (3, Interesting)

Anonymous Coward | more than 4 years ago | (#32068514)

There's excellent competititon for Matlab, foremost NumPy. It has tons of packages, 64bit support, and just works all around a lot better.

Matlab is succeeding not because of lack of competition, but because it's entrenched and people are lazy

Re:I'm not surprised... (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32068526)

I guess no one got around to porting MATLAB to the Alpha architecture.

ISTR that there was a lot of discussion about 64 bit floating point numbers when Alpha was first announced because some folks wanted a certain
number of bits reserved for the exponent, and others wanted a different number of bits. Happily, all that got straightened out, and I don't think
Microsoft was involved in that discussion. It certainly kept the DEC FORTRAN compiler team up at night wondering which "standard" would prevail.

But, as we all know, the nice thing about standards is that there are so many to choose from...

Anything to declare? (1)

LostCluster (625375) | more than 4 years ago | (#32068236)

Dim PowerBallOdds as SuperSizeInt
Dim ChanceOfMeWinning as ExtraAccuFloat
Dim NeedToWorkTomorrow as Boolean = True

What's the deal? (1)

countertrolling (1585477) | more than 4 years ago | (#32068290)

Can't you just move the decimal over a coupla points?

Observations (1)

drolli (522659) | more than 4 years ago | (#32068296)

a) The data types in matlab have absolutely nothing to do with the processor you are running on - and that is good - all my ml programs run on all my machines b) already the 8087 supported 64 bit integer - so no i dont know why matlab does not have it since a long time c) Usually the mathworks people care more about compatibility to the toolboxes. As long as a new feature collides with one of the important toolboxes, they rather don`t introduce it. E.g. if the signal processing toolbox fucks up when being fed 64 bit data

I stopped using MATLAB... (1)

Reik (101256) | more than 4 years ago | (#32068320)

..when they got rid of the 'cool' undocumented commands like 'why' and 'f***'. ;)

there's a llibrary to do this... (0)

Anonymous Coward | more than 4 years ago | (#32068366)

Just use the int64 user contributed stuff:

http://www.mathworks.com/matlabcentral/fileexchange/24725 [mathworks.com]

Python as an alternative (4, Informative)

physicsphairy (720718) | more than 4 years ago | (#32068396)

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 (4, Informative)

Efreet (246368) | more than 4 years ago | (#32068426)

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

Re:Numeric Python (4, Interesting)

mathfeel (937008) | more than 4 years ago | (#32068518)

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

I don't have mod point, so allow me to second that.

The advantage of MATLab for me was ease of development that it allows me to quickly get some simple proof-of-concept code up. If I want run time speed, I'd use CLAPACK and GNU SL. I can't imagine doing any very serious numeric code in anything else (not that my work was very numeric heavy). With NumPy and SciPy, it is just as easy to do what MATLab does in a language that's actually fun to work with.

For what they charge for a license, they should. (1)

mstrcat (517519) | more than 4 years ago | (#32068508)

The price of Matlab (minimum of $2000), more like $10K for a decent set of tool boxes. They charge 20% per year for 'maintenance', though thankfully you don't have to buy a maintenance contract to use the software. And for all of this, they can't be bothered to support 64 bit integers? I'd be asking very pointed questions about why not, if I had a license.

What can it do with 64 bit integers? (1)

Aphonia (1315785) | more than 4 years ago | (#32068562)

You can run the following to find what it supports:
>> methods int64
>> methods uint64

Compare to
>> methods int32
>> methods uint32

Though floating point is very common for matlab use, i think this was fairly common knowledge.

Until someone makes an alternative with all the toolboxes i use, im not switching.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>