Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Math Software Technology Science

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.
This discussion has been archived. No new comments can be posted.

MATLAB Can't Manipulate 64-Bit Integers

Comments Filter:
  • by zippthorne ( 748122 ) on Sunday May 02, 2010 @09:04PM (#32068076) Journal

    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.

  • by straponego ( 521991 ) on Sunday May 02, 2010 @09:15PM (#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.
  • by Anonymous Coward on Sunday May 02, 2010 @09:23PM (#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

  • by forand ( 530402 ) on Sunday May 02, 2010 @10:16PM (#32068512) Homepage
    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.
  • exellent competition (Score:3, Interesting)

    by Anonymous Coward on Sunday May 02, 2010 @10:17PM (#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:Numeric Python (Score:5, Interesting)

    by mathfeel ( 937008 ) on Sunday May 02, 2010 @10:18PM (#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.

  • by Anonymous Coward on Sunday May 02, 2010 @10:19PM (#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...

  • Re:So... (Score:2, Interesting)

    by Revotron ( 1115029 ) on Sunday May 02, 2010 @11:38PM (#32068990)

    Exactly.

    Anyone who's used MATLAB in academia should know this by now.

    In one of my undergraduate courses we were tasked with creating a new method to find pi. In the final stages, our accuracy was severely crippled by MATLAB's failure to handle some extremely long numbers.

    Ironically, Wolfram Alpha was our savior.

  • by goodmanj ( 234846 ) on Monday May 03, 2010 @12:20AM (#32069146)

    Two things:

    1) This is true for 64-bit INTEGERS. The default data type for MATLAB is a 64-bit float, and has been forever.

    2) This is a design decision by MATLAB's designers. You don't have to declare or type variables in MATLAB: you just set a = 5 and a new variable "a" is created. You set a(2) = 3, and now a grows into a 1-d array.

    It's a handy feature and a core aspect of MATLAB's ease-of-use design, but to do this, you need to have a default data type.

    64-bit float is the best choice: you can represent any number up to around 4,503,599,627,370,496 without error. For practical purposes, this means MATLAB will work fine for any real-world integer counting task: it only fails if you're interested in cryptography, primes, or other discrete math tasks, in which case you're not using MATLAB anyway.

  • by thegarbz ( 1787294 ) on Monday May 03, 2010 @12:20AM (#32069154)

    38 downloads may not indicate a lack of demand. The demand may be there, but it may be masked in the confusion of what may be thought to have been a standard part of the program.

    When our uni upgraded the maths lab computers Matlab versions to R2008a they installed the 64bit version as well. The logical thought was that the computers are 64bit, they have the option, so why not. Well at the time the basic add-on packages weren't available for the 64bit version, which included the package with the solve() function. Sure they could have looked on the website and found a few basic implementations of Newtonian solve functions written for 64bit, but their response to student complaints was to remove the 64bit Matlab and install the 32bit version.

    Much like how a pirated copy does not indicate a lost sale, the fact that only few people have "demand" for the application, does not mean there's a lack of demand for the functionality in the 64bit program. It may just mean that people have tried, found it lacking, and dropped back to 32bit. I'd be interested to see stats of how many people use the 64bit Matlab on computers that natively support 64bit instructions

  • by Anonymous Coward on Monday May 03, 2010 @12:36AM (#32069240)

    GNU R, the freetard knockoff of S...

    "Freetard knockoff?" R overtook S-PLUS several years ago in terms of importance among statisticians. Indeed, it's not just in academia where this freetard knockoff has taken over; I work as a quant at an algorithmic trading hedge fund and we dumped S-PLUS in favour of R four or five years ago.

    Sometimes, just sometimes, the open source implementation actually is better.

  • Re:MATLAB ~= fast (Score:2, Interesting)

    by Warlord88 ( 1065794 ) on Monday May 03, 2010 @01:34AM (#32069454)
    Few weeks back, I implemented a simple Monte Carlo simulation in C++ as well as Matlab. C++ was about 50 times faster than Matlab. The problem with Matlab is painfully slow FOR loops whereas the advantage is fast array arithmetic. Many people with traditional programming background do not know how to make use of the latter. There are several special tricks and functions which allow fast computations up to some level. However, if there is no way you can bypass the running of a FOR loop million times, you will get screwed in Matlab.
  • by kestasjk ( 933987 ) * on Monday May 03, 2010 @01:45AM (#32069502) Homepage

    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.

    Linux is plenty commercial, I think you mean "consumer software". (Or at least "proprietary software", but I don't think correlation implies causation there)
    Windows server platforms got behind 64-bit more or less in step with its adoption in servers (even having ports to Itanium, back when that was a credible contender for the next 64-bit arch). Also OSX's transition to 64-bit started with the kernel and worked its way up through the UNIX layer, allowing server apps to use more memory long before consumer apps.

    It has taken much longer for consumer OSes to be 64-bit by default, but that's just because there was no need for it until >3-4GB of memory became common. There's no need for 64-bit Flash like there was for 64-bit MySQL/SQL Server/Oracle etc, and adoption rates have reflected that.

  • Re:Yes but Octave (Score:5, Interesting)

    by orzetto ( 545509 ) on Monday May 03, 2010 @02:14AM (#32069674)

    That's funny. I am researcher and work with math and plotting software on a professional basis, and even when I need Matlab to do the work (e.g. if I have to use nlinfit), I always prefer to export the data to .mat and plot in Octave. Gnuplot's output generally looks better when exported to EPS/PDF.

    Gnuplot does not allow to do GUI editing: that's a big plus, because I am forced, every time, to write a script: I know that if I don't write it, I will miss it later when I want to change something (it always happens). Also, it is much easier in Octave to specify a font (-F:Palatino, for example) than in Matlab: possibly not on top of your list of priorities, but when I wrote my PhD thesis I wanted to write everything with the same font: Matlab plots require you to edit the EPS source.

    3D plots are slow, difficult and complicated things to create.

    Curious. I just published an article with several 3D plots (which I usually eschew), and it was not really more difficult to get things done in Octave than in Matlab.

    3D data is all but ungraphable on Linux systems anyway

    I call bullshit, you never really tried. Have a look at matplotlib [sourceforge.net]. And, that aside, Matlab is available on Linux too.

  • by Anonymous Coward on Monday May 03, 2010 @05:39AM (#32070366)

    integer operations are way faster than floating point operations on most CPUs

There are two ways to write error-free programs; only the third one works.

Working...