# MATLAB Can't Manipulate 64-Bit Integers

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

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.

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

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

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

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

## 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

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

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

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

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

On the principle that if you

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

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

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

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)

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)

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

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

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

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)

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

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

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'tneed 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)

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

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

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)

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

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

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

## #TODO: (1)

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

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

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

## Commercial software lags... (1, Interesting)

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

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

## Re:Commercial software lags... (1)

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

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

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

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

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