Slashdot Mirror
MATLAB Can't Manipulate 64-Bit Integers
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.
How is this news?
Am I missing something here?
"The difference between genius and stupidity is that genius has it's limits" - Albert Einstein
What is the point of having numerical data types that can't be manipulated?
So they can charge more for the upgrade?
#fuckbeta #iamslashdot #dicemustdie
You mean a TUI? There's more to it than pretty windows.
I read TFA and all I got was this lousy cookie
maple 13?
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.
Only if Steve Jobs hit it with a hammer until it was nonfunctional.
Another useful alternative is to use SciPy and NumPy packages for Python. Python doesn't have any issues with dealing with long numericals.
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.
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.
#TODO: finish up all operations for 64-bit integers.
Computers are useless. They can only give you answers.
-- Pablo Picasso
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.
Obligatory.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
As another Engineer that uses MATLAB quite frequently, the only reason I have used 64-bit support was to analyze larger data sets.
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 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 ?
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).
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
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.
Windows still won't read my wireless card. Granted the company does not make windows drivers, but I still think it is windows fault.
I'm hoping that is a joke
When is the last time you've used it? I noticed it has improved over the last few iterations. It precompiles a lot of stuff now, so like FORTRAN of yore, it can do better machine optimization that even a good C compiler can do since it can make better inferences about data types, preallocation, short-circuting of decisions, etc.
But of course, it'll never run real-time or be as efficient as purpose-written code (where you don't need to schlep an interpreter and all that junk along). The Mathworks will happily sell you the automatic code generation from Simulink modules, (for a significant fraction of your yearly salary, AFAIK) those will then run real-time on some CPUs - but I have no idea how good the code generated is.
So yeah. We use Matlab cause you can implement complex algorithms in hours, and visualize the data. If you want to write a pretty app with a GUI, you're using the wrong tool.
And yes, the lack of 64-bit int operations is a non-issue. Wasn't there an article about the old "what every programmer should know about floating point" paper here on /.? Unless you know the issues involved there, you won't understand the issues here.
I'm not 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.
When information is power, privacy is freedom.
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.
Dim PowerBallOdds as SuperSizeInt
Dim ChanceOfMeWinning as ExtraAccuFloat
Dim NeedToWorkTomorrow as Boolean = True
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
If you really want this support, get the user contributed package from matlab central. That wasn't too hard was it?
Can't you just move the decimal over a coupla points?
For justice, we must go to Don Corleone
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
..when they got rid of the 'cool' undocumented commands like 'why' and 'f***'. ;)
Only if it can be vectorized. Otherwise, MATLAB is *bog slow*. Compiling as a MEX function will restore the speed.
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.
You need 64 bit integers for holding indexes into arrays with more than 2 billion elements.
Just use the int64 user contributed stuff:
http://www.mathworks.com/matlabcentral/fileexchange/24725
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.
When things get complex, multiply by the complex conjugate.
Just another reason to switch to numeric python. The more I use Matlab the less I find that I like it.
This sig wasn't worth reading, was it.
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.
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.
May the Maths Be with you!
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.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
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.
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
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.
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
Signedness: Signed
WordLength: 32
FractionLength: 0
RoundMode: nearest
OverflowMode: saturate
ProductMode: FullPrecision
MaxProductWordLength: 128
SumMode: KeepLSB
SumWordLength: 32
CastBeforeSum: true
The documentation is here:
http://www.mathworks.com/products/fixed/
It is true that you need the fp toolbox to do that, though.
We learn from history that we learn nothing from history - Tom Veneziano
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 ridiculous theory. Even counting photons and every known subatomic particle, an index of 2^64 is sufficient to enumerate each and every one with a unique ID that represents that one and no other. In each dimension angles discriminated in units of 1/2^64 of a circle are fine enough for any imaginable purpose.
Given that we are close to understanding these elements, 128 bits would probably be a more durable unit. 128 bits should give us a few more years of discrimination before the physical sciences discover even finer units of time, mass and distance. Some even theorize now that 64 bits are the limit: that space, mass and time have a granularity and that finer resolutions are absurd. To that I say...
If software must be designed with limits it should use limits so absurd that no user no matter how hypothetical could be constrained by those limits because the designer does not know how long his application will persist nor how its use will evolve.
It's not the most efficient design that wins. Ultimately it's the most persistent.
Help stamp out iliturcy.
So it clones Matlab very well then.
Mathlab is for doing MATHS, as its name hints. Who cares about integer when you have floating point in the maths world ?
You should take a look at qtiplot or scidavis. Both programs can create 3d plots and export them to pdf.
Also, matplotlib (pylab) has some extensions that allow for 3d plotting and can also export to vector formats.
If you're really serious you could generate the data as an image or vtk file and open it in paraview, which cannot export vector formats, but is a _very_ capable visualization tool.
Only if it uses mostly the functions that are coded in C. If you, god forbid, need to write something of your own, particularly if it includes loops, you're hooped.
How about subtraction?
I have left slashdot and am now on Soylent News. FUCK YOU DICE.
Heh while we're bitching about MATLAB data types, where are the sparse single matrices?? Bah!!
So, maybe most people don't use over 90% of MATLAB's features. Does that mean MATLAB is bloated? Well, the thing is, everyone has different needs, and use a different 10%. Granted, most people have no use for 64 bit integers, but I'm sure somebody does, and somebody is mightily annoyed that their software that cost thousands doesn't do it.
Huh. People actually use MATLAB outside of academia? All the scientists I know who do hardcore math use FORTRAN or IDL.
Actually, Mathworks sent out a call for potential beta testers for GPGPU. I believe they plan on adding it to the parallel computing toolbox. So you'd have to pay extra if you want to access your GFX card for computational stuff. There is currently a free Matlab GPGPU toobox: http://gp-you.org/
Another thing that annoys me is the deathly slow Java interface in Matlab. Even with a fast 3D card it can take ages to manipulate complex 3-D plots.
3D data is all but ungraphable on Linux systems anyway, so I suppose Octave is not alone here.
As I recall, MATLAB has a Linux port. As does Maple, Mathematica, et cetera. And Mayavi is an open source program capable of excellent 3D graphics that works with Python, and therefore SciPy.
So what you really mean is that 3D data graphing is inadequate with Octave and gnuplot on any system. 3D data is perfectly graphable in Linux.
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.
pssh, you guys are a bunch of nerds
And are afraid to tell anyone. Another possibility is they fired 'the guy' who knows how everything works and now they can only make cosmetic changes.
http://junglevision.com -- Shamus for Gameboy
I recall reading an article back when 16 bit CPUs were a new thing which promoted the idea that 8 bit CPUs were superior for text processing because text was basically 7 bits.
http://michaelsmith.id.au
I'm hoping that is a joke
Joke or not, it's reality for anyone dealing with fixed point math. You have to go through your entire algorithm and decide which bits are worth keeping and how many you need. Things like Hamming windows don't like it when an accumulator overflows.
So you have to figure out how many numbers you're adding, take ceil(log2(N)) of that, and that's how many extra bits you need, or more to the point, how many high bits that the input data can't use. If N gets really big, that can cut way into a 32-bit integer. Trying to drop least-significant bits at various points in the vector raises your noise floor, decreasing your SNR (the noise looks like regularly-spaced impulses, too, which can hurt a clock-recovery algorithm). Also, this bit-eating effect cascades.
Multiplication is even worse: you get as many bits out as the sum of the bit counts in; 32x32 => 64.
As for Matlab... so what. Seriously. Matlab went for a very long time supporting only double precision floats (heck, it went a long time only supporting 2-D matrices). Other types were only supported in I/O; they got converted to doubles internally. They added 8-bit integers to make the video processing people happy back in the days of 3dfx. Then they added floats because some people wanted to trade precision for storage space, and integers because the fixed-point simulation stuff was getting hard to do. It's really a case study of a 90% solution.
For 18 years, I've worked at a research lab that swears by Matlab. (Though their recent licensing costs have us moving a lot of stuff to Python, and we tried Octave but dumped it because we couldn't migrate to it because they were missing key features that they didn't believe they needed. Our sponsors don't pay us to drop everything to learn Octave's internals, write patches to support what we need, and fight Octave politics to get those patches in.) And in all that time, the number of times I've seen anyone use integer arithmetic... is zero.
The vastly larger dynamic range, and logarithmic scaling, of double-precision floating point worked just peachy. Slow and memory hogging at times, to be sure. But we could crank out test algorithms in Matlab far faster than C++. Now... Python, NumPy, matplotlib... we're slowly moving over.
Python is a far more serious language than Matlab. Matlab is a hacking language like BASIC. It's lousy to manage a big project with. Seriously, one file equals one function? A class is a directory starting with an @? And there's no way to do select(), so we can't hook it up to our TCP/IP sockets and serial ports at the same time? And we're paying how much?
If you're serious, develop your algorithm in Python. 90% of the time, it'll be fast enough; the other times, you were going to have to write it in C or C++ anyway, and if you wrote your code in Python, your code will be far closer to C or C++ than if you wrote in Matlab. You'll never worry about licensing. Forget Octave and Matlab. And don't get me started on Matlab-to-C compiler. (Short version: if your program is read-compute-write-terminate, it might work for you. If it's event driven, forget it.)
You should check out some of the newer versions of Octave. The graphics in versions 3.0 and 3.2 are very much improved. (Disclosure: I was an active Octave developer a couple of years ago.)
If 64-bit integer A is less than 64-bit integer B, where are you going to hide the negative sign?
3D data not graphable on linux. Are you kidding? Try Visit from LLNL, freeware and enables
analysis of multi-terabyte datasets on either single or multi-core systems. Other options exist,
such as Paraview or Mayavi2, both of which are free. All of these offer python scriptable
interfaces. In fact, I'd be wonder why anybody would want to use any kind of commercial
software, or anything related to Octave for data analysis today.
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.
I don't know what you mean; you can do a lot with handle graphics in MATLAB...
So it clones Matlab very well then.
Matlab 3D plots are usable, things like surface plots are about as easy to code as 2D plots (i.e. they're one command), and you can just drag the 3D graph around until the camera is where you want it. So, no, Octave doesn't clone Matlab very well.
And this is a real problem ... how exactly? Using MATLAB for courses consisted almost entirely of writing scripts and typing a few commands into the prompt. (I presume that we did something involving the GUI at some point but it evidently wasn't memorable.) The only real benefit I gained from MATLAB having a GUI was that they implemented a better terminal than I'd expect to find otherwise on the uni's windows machines. I don't bother installing an octave GUI because it makes about as much sense as installing a GUI for ksh.
Actually, you're probably best off dumping your data to text and then running gnuplot (or whatever plotting tool you prefer) separately. Octave has problems submiting to gnuplot that simply don't pop up when I use gnuplot directly or through a perl script (e.g. finding fonts when exporting to png which is what prompted me to try separating out plotting in the first place).
Commercial 64 and 128 bit computing has been reserved for military/intelligence work for some time and they don't let this thing get out in the public quickly.
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.
No, it's a carry. Adding a number with the 63rd bit set to a number with the 63rd bit set is an overflow.
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.
I think it's
gnuplot could be better (the documentation isn't great, a well designed GUI to get you started would be nice), but it's not too bad. With imagemagick's convert and a bit of shell scripting you could get some animation going without too much fuss.
Really I've never come across a graphing solution which made me think "wow, this system has got it right", not in stats packages, langauge libraries/packages, spreadsheet apps, math systems, graphing apps, nowhere. I'm not sure why that is, but I guess it must just be hard to model something that has to be so flexible in a neat way.
// MD_Update(&m,buf,j);
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.
It's a slashumiliation, or humiliation by slashdotting.
I once had a signature.
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.
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.
I call bullshit, you never really tried. Have a look at matplotlib. And, that aside, Matlab is available on Linux too.
Victims of 9/11: <3000. Traffic in the US: >30,000/y
If you want raw speed, you don't code in Matlab. Simple.
It depends. To develop for Matlab is much faster. Matlab code can be very fast if you do certain things (size matrices beforehand and vectorize all code).
I usually write the program in Matlab, try to speed it up in Matlab (vectorize, etc...) and then start writing Mex scripts to replace slow parts. I also try to get it working in Octave - for the simple reason that Matlab licenses are often limited to one per PC (instead of one per core) and it makes simulations slow.
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. http://welcome-to-croatia.com/
not "overflow error". The carry bit is in the conditions register that all self respecting CPUs use for conditional branching and instructions like "add with carry". It's nothing to do with 64 bit, as the same concept works for 8 bit processors.
Other examples of where Octave has much better potential than Matlab are:
1) Calling matlab-like matrix functions from another programming language.
2) Using Octave on an architecture other than x86.
3) Using Octave on mobile devices.
I used Matlab extensively during my PhD (Physics), but am now switching to Python (and slowly rewriting all my code). I started because of the ridiculous licensing for Matlab, but continue because Python just has fewer stupid bugs like the submission talks about. The only thing I miss about Matlab is the extensive documentation all collected in one place and presented nicely.
My scientific language of choice is MS Excel. What's a double?
Matlab's plotting isn't good at all. Try some 3D plot and you'll see that the axis labels has a life of their own. It also cuts off the image if your label is to large (even in 2D).
In the scientific community, Linux is the best choice by far. You have anything windows has and more. I have not seen any commercial software that isn't available for linux and mac as well.
And Octave does have a GUI. (qtoctaave)
Myself I am developing HornetsEye which is a Ruby-extension for doing computer vision.
The problem with supporting various types is that you end up with a lot of possible combinations when doing computations. I.e. say if you want to support arrays of 8-, 16-, 32-, and 64-bit integers (signed and unsigned) as well as 32-bit and 64-bit floating point, you have 10 ** 2 possible combinations of types when element-wise adding two arrays.
If speed is not an issue however, you could just use Ruby's dynamic typing. Ruby's integer classes use dynamic typing in their computations in order to avoid numeric overflow:
( 10 ** 2 ).class
# Fixnum
( 10 ** 10 ).class
# Bignum
Also you can seamlessly combine rational numbers, big numbers, complex numbers, and matrices in a seamless way which is really neat:
require 'mathn'
2/4
# 1/2
( Complex::I / 2 ) ** 3
# Complex(0, -1/8)
1 / 2 + Complex::I / 3
# Complex(1/2, 1/3)
( 1 / 2 + Complex::I / 3 ) ** 5
# Complex(-199/2592, 61/3888)
( 1 / 2 + Complex::I / 3 ) ** 24
# Complex(584824319281/4738381338321616896, 161741277005/32905425960566784)
a = Matrix[ [ 2 / 3, 3 / 4 ], [ 4 / 5, 5 / 6 ] ]
# Matrix[[2/3, 3/4], [4/5, 5/6]]
b = a.inv
# Matrix[[-75/4, 135/8], [18, -15]]
a * b
# Matrix[[1, 0], [0, 1]]
R plotting is better than both. There is zero problems with large 3D datasets. I do it all the time. On Linux.
The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
QTIplot. It's open source. Pre-compiled binaries are free on LinuxMacOSX and require a small support license on Windows. The graphing capabilities of this program are quite good.
I make it twice that - 9,007,199,254,740,992. 52-bit mantissa, plus hidden '1' bit = all 53-bit numbers, so you can go up to (and including) 2^53. The next representable is 2^53 + 2.
> 3D data is all but ungraphable on Linux systems anyway,
? eh, you must be looking very hard in the wrong place.
for one, try Paraview. ... (including my favorite)
for two, try VisIt.
for three, there are many more like that
There's been talk about matplotlib with octave since 2005. What's the current state?
I'm not an advanced math researcher or scientist, so my experience with MATLAB and Octave has been somewhat limited. However, when I did my multivariable calculus and linear algebra homework, I found Octave to be just as easy to use as MATLAB and it did not plot graphs any slower than MATLAB did, even in 3D.
Gnuplot can do quite a lot too.
Now, Matplotlib, in Python, was designed to clone the MatLab plotting facilities. Then someone tied it into vtk..
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.
Even the statically linked "operating system" in a Nintendo 64 game console? That thing had only 4 MB of RAM and thus used 32-bit pointers, but it was still 64-bit.
There's no need for 64-bit Flash like there was for 64-bit MySQL/SQL Server/Oracle etc
Perhaps that's why a lot of Flash games still appear to be stuck in the 16-bit era of 2D.
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.
I call 'bullshit' right back. =] There's an aptly-named "FontName" text property in MATLAB.
--
x = linspace(0, 3*pi);
y = sin(x);
plot(x, y);
text(pi/2, 1, 'Maximum at \pi/2', 'FontName', 'Palatino');
--
I hate matlab - there I said it, it is an abomination, no types so when you look at a piece of matlab code you have no freaking idea what it is supposed to do - is that variable an array, an int a float, data structure? who knows? variables appear out of nowhere - aaagh! just stop it already and learn a real language.... the five minutes you think you save using matlab ends up costing 5 hours to someone else who wants to use it.
Depends on the task - on vector and matrix operations Matlab is about as fast as FORTRAN (or C) but function calls, thus recursions are slow. I had one highly recursive algorithm that ran 1000 to 10000x (stet!) faster in C. Our Matlab field rep.couldn't believe it, asked for the Matlab code so he could "optimize" it. Never heard back from him... To give it its due, Matlab is one hellova a number grinder / matrix manipulation language, just don't try to use a use a Honda S2000 as a dump truck.
'What is the point of having numerical data types that can't be manipulated?'"
How about the point is you can store the result of two 32-bit numbers being added or multiplied? Moron?
yes, thats right, my dynamical systems are so sensitive to perturbation in their initial conditions that i require quad prec, i need 128bit floats (you insensitive clod). the intel fortran compiler supports 128bit floats, aka quad precision, with their compiler ifort. But their _optimised_ version of lapack in their mkl (math kernel library) doesnt handle 128bit floats properly. ive tried handing gemm real*16's and gotten nonsense answers, im guessing that the optimized code does even realise its been given a different data type and interpreting the quad prec's as double's and only reading the first (or last depending on machine arch) half.
intel processors have incorporated 80bit registers in the fps for some time. (the itanium has more i believe).
so real*10 should be fully supported and run at fully optimised native speed, but i can accept a slow down with quad prec, but if its supported by the compiler why not allow the mkl to make use of it. i havent benchmarked the speed difference either but im interested now. i might just grab some netlib codes for gemm aand compile them with real*16
the limit of defining arrays with more than 7 dimensions in the latest ifort, to be stored with hdf5.
it kinda weired me out to get the error msg back from the compiler that _any_ number of dimensions was not supported. i mean sure with an array of doubles, at 4bytes per element a 8 dimensional array with 1:10 extent in each dimension is going to require a mere 382meg. so why cant i declare such a variable on my machine with 4gig?
Matlab's one and only numerical data type is actually a matrix of complex numbers.
challenge accepted
Why learn one language for image processing algorithms when you still have to learn other languages to do everything else? Better have one language that does everything.
No doubt they are (3.2 is the only Octave version I've used so I can't compare against the older version), but they still look like crap compared to Matlab. Gnuplot does OK with 2-D (line) graphs, but its surfaces just look awful. Also, Matlab's graphics handles give you complete control over the appearance of every item in the plot (including call-back functions for user interaction). This level of control simply isn't possible with Octave.
-JS
If you really want this support, get the user contributed package from matlab central. That wasn't too hard was it?
Disclaimer: I'm the dev, but I'm surprised that an iPhone/iPod calculator manages to do what MatLab does not:
Perpenso Calc, decimal arithmetic, 20 decimal digits, fractions, complex numbers, RPN
It is like saying if I put a Ferrari engine in a Chevy Suburban, it will perform as well as if i put it in a Ferrari.
Another way of putting it might be to say that, while both vehicles would then use the same engine, the Ferrari uses code structure recognition heuristics to optimize the sequence of calls it makes to the engine, while the Chevy takes a simpler approach to generating its sequence of calls.
I may not have made a very good analogy at all, I'm afraid...
Bow-ties are cool.
The difference is for Engineers versus Scientists. Engineers, who I would argue are far more likely to use MATLAB, have 0 need (with 0 being less than eps) for 64-bit integers because you will never ever ever ever measure data with accuracy of 1 part in 9,007,199,254,740,992, or anywhere near that. And as a rule, we have no need for integers because measured data and functions of measured data are much better represented using floating point. Scientists, who do work in absolutes, would have this need, but I would argue that they would not use MATLAB anyways and use something like Mathematica because it can do all calculations without losing any accuracy.
Ever.
Bow-ties are cool.
What I meant in particular was that, since the plotting facilities are tied closely to MATLAB, it's possible to do things like build interactive simulations, and do real-time animation. AFAIK the only way to do animated plots with Octave+GNUplot is to pre-generate a sequence and then play it back like a movie, which would leave much to be desired. That said, I have admittedly not invested much time in trying to get GNUplot to do this sort of thing so it may actually be possible; if it is I wouldn't mind a pointer to e.g. a tutorial.
Python+matplotlib seemed very promising though. I liked them when I tried that combo out, but not enough to switch (mainly, MATLAB's matrix/array syntax is kind of wonderful).
I'm sometimes tempted to just use some nice C++ math libraries and do everything there, though; code can be an order of magnitude faster or more than either Python or MATLAB. E.g., a one-off script to solve a particular PDE took about 10 minutes to run in MATLAB (it was stuff that couldn't be vectorized well); nearly identical C++ code ran in about 10 seconds. Likewise (another example), for a project in planning algorithms for a class I was auditing, one team implemented a very clever algorithm in Python and another did something more naive in C++; the C++ team's planner was much faster despite being "dumber" simply because of the interpreter overhead that the Python team was saddled with. So I'm tempted by combos like C++ with the 'eigen' library.
No need to use C++ exclusively, just write your algorithm in it and use one of the wrapping methods to make it available in Python. You get C speed and Python ease.
You can do the same thing in MatLab, of course, but I found MatLab wrapping a lot more work than even by-hand wrapping for Python, and there are a variety of tools to help out with the latter, all the way up to fully automatic.
As of version 0.10.6, SmallBASIC can do 64bit operations and it supports many math functions - http://smallbasic.sf.net
I have a project that is not 'most work'. Matlab solves matrix problems for me that neither Mathematica nor any other package I've tried can. Matlab's competence shows in its description of mldivide, which is the key to my problem. It says that it tries A unless condition B is true, in which case it tries C, .... Mathematica says, trust us because we're so smart, with 1000s of routines, 1000000s of LOC etc. w/o going into details. All the free packages are jokes in this area. The only competition would be perhaps some C++ library. However Matlab probably hired its author to extend it for them.
Open SW is nice if you're not picky, but the commercial stuff, in many cases, does specialized things better.
I want an option in Matlab to start its array indexing at 2. Then I'll start using it.
Put a loop on your code, and you'll see how Mathlab craws. It slows down more than proportionaly to the number of iterations.
Rethinking email
For a lot of applications, speed isn't the limit, development time is. I use Matlab a lot (I'm an accelerator physicist), and most of the time the programs run almost instantly on a modern computer. I'm mostly interested in a language that lets me develop quickly. I almost never use integers so the lack of 64 bit integer arithmetic isn't a problem - didn't even know about the lack until seeing this.
I've tried Scilab, Octave and Python for this sort of use, but I've found Matlab best meets my requirements - but of course depending on the the application, different languages will be superior.
That's a good point. The system should care about doubles for a scientist in the field other than engineering and cs, or the caring should be optional.
There are many ways to avoid for loops in MATLAB. If there isn't a way to avoid the for loop it is usually because of the number of operations that are going on in the loop. If that many operations are going on in the for loop than the overhead of the for loop is diluted.
Depending on the Monte-Carlo simulation, I will have one iteration of the "for" loop execute many iterations of the Monte-Carlo. If I can't do this, than typically the overhead of the for loop isn't that significant.
The point is, MatLab is very slow. MatLab functions that are written in C are pretty much as fast as C (they really should be) but MatLab itself is very slow, just like any other interpreted language.
In general having a bigger loop is not faster than a smaller one. The overhead isn't in the loop, it's in the interpreter having to reinterpret each go around, unless it happens to be a hybrid interpreter that actually figures out the loop, compiles it, then runs it (like Java).
The speed of MatLab is only comparable to that of C if you're running canned MatLab C functions. If you have to write any sizeable amounts of code that MatLab actually has to interpret, it will be slow. That's most obvious with a loop but also plays a role even without loops, for large enough programs.
There is a QT based GUI for Octave avilable at
http://qtoctave.wordpress.com/
I tried it just out of interest some time ago and it looked ok to me, but then I had other things to do and did not really use it.
Also there is EIDMAT
http://eidmat.wordpress.com/ or
http://sourceforge.net/projects/eidmat/
but I did not try it
Also check out QTOctave
http://qtoctave.wordpress.com/
and EIDMAT
http://eidmat.wordpress.com/
http://sourceforge.net/projects/eidmat/
Actully i blame the manufacture, they could get a mainline kernel driver for the cost of a unit of hardware. www.linuxdriverproject.org. Ohh look free driver development, now why haven't they done it yet? ohh right they don't care.
All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
Sigh ... sure wish I hadn't lost that source code. Back in '86 or so, Turbo Pascal and 8086 assembly language (oh yeah!) ... Toad's Infinite Integer Math. You could do all the basic math functions (add, subtract, multiply, divide, roots, powers) on integers whose length was only limited by the storage on your hard drive :-) Basically a calculator with a HUGE display screen :-) And with the largest numbers you can imagine treated as nice clean pure integers, no steenking floating point for us, unh unh! (Hell, my motherboard didn't even HAVE a math chip! Probably a Z-80 as I recall.)
Yeah, huge arrays of bytes, and simple functions that chugged through them, digit by digit :-) Worked great. Russian Peasant Algorithm, that sort of simple stuff, just with LONG numbers. And then a buddy on Usenet who heard about it sent me some more code that did some higher level math (logarithms and I forget what all; I'm no mathematician, just knocked it out as a lark).
Sure was fun, being able to manipulate numbers that were higher than the probably number of atoms in the Solar System, that sort of thing :-) And that was '86, small hard drives, 8-bit processors. Imagine what I could do with that now! Muah hah hah! The mind boggles!
But the hard drive with the source failed, the backup floppy was corrupted, my correspondent (who possibly had a copy of the source) dropped off the face of the earth, I couldn't find anything on Usenet or the usual sources. Gone gone gone [sob].
Toad of Toad Hall
Woah! Just did a search (since I hadn't looked for this for years) and ... lo and behold! Found! Discovered! Yesssss!
http://drn.digitalriver.com/category/Borland-Turbo-Pascal-programming-language/296.html
Which leads to this download:
http://drn.digitalriver.com/free-download/Borland-Turbo-Pascal-programming-language/toadlongzip/51197.html
TOADLONG.ZIP! And it's all there! Enjoy :-)
(Yes, the old Turbo Pascal compilers are still out there too.)
Boy, that WAS back in The Day. Check out my old email address :-)
kirsch@braggvax.ARPA
Hmmm, I wonder if that's still working?
Toad
Sage has very fast 3d plotting capabilities! http://www.sagemath.org/
I believe MATLAB isn't strictly interpreted anymore, but instead does just-in-time compilation.