Forgot your password?
typodupeerror
Math Software Technology Science

MATLAB Can't Manipulate 64-Bit Integers 334

Posted by kdawson
from the does-not-compute dept.
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:
  • So... (Score:5, Insightful)

    by Anonymous Coward on Sunday May 02, 2010 @08:41PM (#32067898)

    How is this news?

    • by welcher (850511) on Sunday May 02, 2010 @09:29PM (#32068248)
      If you really want this support, get the user contributed package from matlab central [mathworks.com]. That wasn't too hard was it?
      • by ProfMobius (1313701) on Sunday May 02, 2010 @09:39PM (#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.
        • by welcher (850511) on Sunday May 02, 2010 @11:48PM (#32069036)
          The point is that very few engineers currently want or need this functionality -- if they did, the Mathworks folks would surely be on to it. The native type is defined, abstract methods are waiting there to be defined, and someone who needed it has implemented it and made it available. Incidentally, that package has had 38 downloads since july, perhaps indicating the level of demand. From this thread [mathworks.com], it looks like the company is waiting for the demand before implementing it themselves.
          • 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 sadtrev (61519) on Monday May 03, 2010 @03:40AM (#32070004) Homepage

            using 64-bit integers instead of floats is a common trick in embedded C for control and signal processing on low power processors. I have experience of four different embedded systems used in commercial products from three different companies I've worked with - three of the four used 64-bit integers for roundoff-sensitive calculations.
            I was a bit surprised that Matlab can't handle this, but then I've seen the poor quality of the ostensibly production-ready code that comes out of their M2C converter - it was about ten times the code footprint and a fifth the speed of a minimally-optimised C version of the same algorithm.

            Honestly, I don't know how anyone can justify paying for this, when R (and even Octave in this instance) is more capable. Where the target platform requires C or asm code, then doing development in Matlab is usually more trouble than it saves. The graphs are prettier, though.

    • Re: (Score:3, Insightful)

      by creimer (824291)
      I will give you a numerically precise answer... DANGER, WILL ROBINSON, DANGER!
  • by XPeter (1429763) on Sunday May 02, 2010 @08:42PM (#32067910) Homepage

    Am I missing something here?

  • Answer (Score:3, Insightful)

    by girlintraining (1395911) on Sunday May 02, 2010 @08:43PM (#32067918)

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

    So they can charge more for the upgrade?

  • by Anonymous Coward

    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.

    • by wizardforce (1005805) on Sunday May 02, 2010 @08:50PM (#32067994) Journal

      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.

      • by robot256 (1635039) on Sunday May 02, 2010 @09:05PM (#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.
        • by Jeffrey Baker (6191) on Sunday May 02, 2010 @09:08PM (#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.

          • 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

            • What do you expect the RDBMS to do in this case? It returns a 64-bit integer value. Then R reads it and silently casts it to a double, which silently swizzles the low 12 bits.

              Since YAAS, should I stand back [scienceteecher.com]?

        • Re: (Score:3, Informative)

          by Nutria (679911)

          But fp is, by nature, slightly imprecise. Really, Really Small numbers would get lost in the noise.

          • Re: (Score:2, Informative)

            by orkysoft (93727)

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

        • Re: (Score:3, Interesting)

          by forand (530402)
          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: (Score:3, Funny)

          by smallfries (601545)

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

          O RLY?

      • Re: (Score:3, Insightful)

        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.

      • by KibibyteBrain (1455987) on Sunday May 02, 2010 @10:27PM (#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.
    • by seeker_1us (1203072) on Sunday May 02, 2010 @08:51PM (#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: (Score:3, Insightful)

        by Anonymous Coward

        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 w

      • Re: (Score:3, Insightful)

        by nedlohs (1335013)

        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.

    • by symbolset (646467)

      It's best to design software for limits that are frankly absurd. Since I coined the phrase "absurd limit theory", let's delve a little bit into it.

      A second divided into increments enumerated by fractions of a 64 bit integer is less than the differential travel of differing wavelengths of light over a planck unit of distance. It's a smaller unit of time than matters to our current understanding. 2^64 seconds is more time than the entire history of our Universe from beginning to end even in the most ridic

    • by ceoyoyo (59147)

      You better not be crunching numbers that size in MatLab.

  • by TerribleNews (1195393) on Sunday May 02, 2010 @09:03PM (#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: (Score:2, Insightful)

      by WeatherGod (1726770)
      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: finish up all operations for 64-bit integers.
  • by dissipative_struct (312023) on Sunday May 02, 2010 @09:04PM (#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: (Score:3, Informative)

      by coolsnowmen (695297)

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

      by ClickOnThis (137803)

      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 eff

    • Re: (Score:3, Informative)

      by pjabardo (977600)
      Actually, if you you are working with very large data sets you might need to index using 64 bits. A friend of mine who knows very little programming was using matlab to compute all eigenvalues of a large operator. It was all working fine until he started to use his scripts on larger problems. At the time, a couple of years ago I had to recompile octave to use 64 bits as the default integer and the program just worked fine with the larger data-sets. The 64 bits integer was available as a configure option so
  • by usul294 (1163169) on Sunday May 02, 2010 @09:14PM (#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.
  • 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.

  • 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 larkost (79011)

      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

    • Re: (Score:3, Interesting)

      by kestasjk (933987) *

      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

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

    • I'm hoping that is a joke

      • 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.
  • I'm not surprised... (Score:5, Informative)

    by Jah-Wren Ryel (80510) on Sunday May 02, 2010 @09:27PM (#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 (Score:3, Interesting)

      by Anonymous Coward

      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: (Score:2, Interesting)

      by Anonymous Coward

      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

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

  • 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
  • by physicsphairy (720718) on Sunday May 02, 2010 @09:54PM (#32068396) Homepage

    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)

    by Efreet (246368) on Sunday May 02, 2010 @09:59PM (#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 (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.

      • Re:Numeric Python (Score:4, Informative)

        by Kensai7 (1005287) on Monday May 03, 2010 @02:35AM (#32069778)

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

          by Kensai7 (1005287)

          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.

  • 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.
  • While this is not implemented natively, (or at least not until you use the fixed point tools to auto-generate some code for a 64bit machine), you can do a lot of fixed point math with the fixed point toolbox:

    For example:

    >> x=fi(5,1,64,0,'SumMode','KeepLSB');
    >> y=fi(23,1,64,0,'SumMode','KeepLSB');
    >> x+y

    ans =

    28

    DataTypeMode: Fixed-point: binary point scaling

  • by Obsolete Disks (1802836) on Sunday May 02, 2010 @11:01PM (#32068794)

    What do we do when the value of 1 starts to float away?
    QT/Octave:

    >>> sqrt(-1)^((4)^1)
    ans = 1
    >>> sqrt(-1)^((4)^15)
    ans = 1
    >>> sqrt(-1)^((4)^16)
    ans = 1.0000e+00 - 2.6298e-07i
    >>> sqrt(-1)^((4)^17)
    ans = 1.0000e+00 - 1.0519e-06i
    >>> sqrt(-1)^((4)^21)
    ans = 1.0000e+00 - 2.6929e-04i
    >>> sqrt(-1)^((4)^22)
    ans = 0.9999994 - 0.0010772i
    >>> sqrt(-1)^((4)^32)
    ans = 0.56253 + 0.82678i
    >>> sqrt(-1)^((4)^40)
    ans = -0.97448 + 0.22446i

    The fractal community will be outraged.

  • 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 highegg (1802934) on Monday May 03, 2010 @02:02AM (#32069586)
    Being the guy who implemented the proper 64-bit arithmetics support in Octave 3.2, I can maybe share some interesting points. Matlab's design choice of double as the default type is both a blessing and a curse. Usually the blessing strikes you first (I always disliked it that 1/2 is 0 in C++ and Python, finally Python 3 changed that as well), but you start to feel the curse when diving deeper, and integer arithmetics (which I agree is far less used than floating point) is a perfect example. Initially, Matlab probably had no integers. Given that double is the default, Matlab creators decided to make the integers "intrusive", in the sense that integers combined with reals result in integers, not reals, contrary to most other languages. The motivation is probably so that you can write things like a + 1 or 2*a without a silent conversion. Hence, when I is integer, D is double and OP is any operator, I OP D behaves like int (double (I) OP D). Except that things like a + 1 seem to be optimized (something Octave currently lacks, but it shouldn't be hard to do). int64 is where things start to get messy, because not all 64-bit integers can be exactly represented in double. So, using the simple formula above, 0.5 * i64 could occassionally do something else that i64 / 2, which is highly undesirable. In order to do the "right thing", Octave will choose one of two options: first, if it discovers that "long double" is at least 80-bits wide (so that it can hold any 64-bit integers), it will use that to do the operations. If not, it will employ a custom code to emulate the operation as if it was performed with enough precision. It's based on manipulating the mantissa and exponent of the double and is much slower. Although it was kinda fun to implement it, it is really a lot of work for too little music, so that can partially explain MathWorks' attitude to this. Unlike Octave, MathWorks doesn't really need to aim at source portability (as they just distribute binaries), so maybe they're just waiting for proper long double support in all compilers they use, and then they will just use the simple approach. Or maybe they're waiting for some important future design change. When I implemented this, I was fully aware that it's not a killer feature, yet I thought it may make Octave more interesting to some Matlab users. So I'm glad someone noticed :) In any case, I suppose at some point Matlab will support this as well.
    • Dynamic typing (Score:3, Informative)

      by janwedekind (778872)

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

I cannot conceive that anybody will require multiplications at the rate of 40,000 or even 4,000 per hour ... -- F. H. Wales (1936)

Working...