GNU Octave 3.0 Released After 11 Years 222
Digana writes "GNU Octave is a free numerical computing environment highly compatible with the MATLAB language. After 11 years of development since version 2.0, stable version 3.0 released yesterday. This version is interesting because unlike other free or semi-free MATLAB competitors like Scilab, specific compatibility with MATLAB code is a design goal. This has manifested itself in goodies like better support for MATLAB's Handle Graphics, a syntax closer to MATLAB's own for many functions, and many functions from the sister project Octave-Forge ported to the core Octave project for an enriched functionality closer to the toolboxes provided by MATLAB. GUI development is underway, but still no JIT compiling, which is a show-stopper for Octave newbies coming from MATLAB with unvectorized code."
Help them (Score:3, Informative)
Re:Good and bad news (Score:2, Informative)
I suppose you mean the spaces vs. tabs thing, maybe you're right, but no one can deny that Python has an extremely simple syntax.
You can do anything with it, from HTML parsing [crummy.com] to a game physics engine [sourceforge.net] to 3d graphics [sourceforge.net] to Excel spreadsheets [markcarter.me.uk] to... you name it.
Even if Python isn't quite enough for your needs, you can very easily link it with C language [swig.org] or Fortran [scipy.org] modules in a trivial way.
If I have an alternative that is, at the same time, simpler and more powerful, then why should I bother with this whole Octave/Scilab/Matlab mess?
Re:Good and bad news (Score:3, Informative)
Then I have great news for you, there's single package [enthought.com] that you can download for free and it will install everything you need to develop scientific programs in Python in a Microsoft computer.
Even if you have years of experience in Matlab, try it, you have nothing to lose. Wherever possible, they made the function calls the same as Matlab's [sourceforge.net].
Re:11 years to switch between 2.0 and 3.0 (Score:5, Informative)
For example, in KDE 3, a KDE 3.0 app would run on the latest KDE 3.5.8 libraries, but not on KDE 4.
The second number indicates new API. a program written for, say, KDE 3.5 might not work on KDE 3.4 if it uses any of the new functions.
The third number is just minor patches and fixes, and shouldn't break anything.
Development accelerating (Score:4, Informative)
You're right, it's not obvious (Score:2, Informative)
In the case of the Matlab 802.11 model, every part of the protocol is implemented. That means you can look at the guts of the whole thing. Not only that but the channel is modeled for a fading channel. You can look at the eye diagram and watch the eye close as the s/n ratio deteriorates. You can also watch the constellation deteriorate from 64 tight dots to two blobs.
As a teaching tool, the model is amazing. In theory it could be done in any language (just about) or on any hardware (as long as speed doesn't matter). In practice, it was created in Matlab.
Re:Well, if they ever become competitive to Matlab (Score:5, Informative)
I've called them with a fairly high level support problem. I got patched directly through to an engineer and within 7 hours (we had been pounding our heads against the wall for a week) we had a solution.
I've heard numerous other stories of similar fate (which is where I got the idea to call).
While Octave is fine for supporting *most* of the features of Matlab. There is a segment of the market that Octave is never going to touch. Simulink, most of the extra toolboxes, direct from Simulink to ECM Flash software. Some of the high level Power Sim blocks, hardware in the loop stuff (From dSpace). "Matlab" is just the tip of the iceberg when it comes to Mathworks software. We even have people writing S-Functions, I'm picking up MEX to speed up some data routines.
I live and breathe on Matlab and for most of the stuff I do, Octave won't touch it. For 'us' Octave will never be competitive.
Re:Good and bad news (Score:2, Informative)
Re:11 years to switch between 2.0 and 3.0 (Score:3, Informative)
To be very precise (at least for libraries that use this scheme):
There is no compatibility across major number versions. Applications built against a library of one major version are not expected to run with libraries of any other major version. API changes of any sort are allowed. Interfaces may be changed, added or removed.
There is forward compatibility across minor versions. An application built against library version x.y.z will run with any library with minor number y or greater. This means that API extensions are allowed, but API changes or removals are not.
There is forward and backward compatibility across sub-minor versions. An application built against library version 3.5.8 will run with library 3.5.1. This means that API changes of any sort are disallowed.
Compatibility (Score:3, Informative)
Re:11 Years? (Score:4, Informative)
Re:cat gack (Score:3, Informative)
For an interesting post by the lead developer of Sage (William Stein) on the relationship between Sage and Octave in terms of overall goals, see this http://sagemath.blogspot.com/2007/12/why-isnt-sage-just-part-of-octave.html [blogspot.com]
--Mike (a Sage developer)
Re:Well, if they ever become competitive to Matlab (Score:5, Informative)
MATLAB did the same thing to us, made us pay maintenance for all the years that it had lapsed, because we wanted to upgrade an users' desktop to the latest version.
Guess what my desktop runs now?
Re:11 Years? (Score:3, Informative)
local$ ssh -X solaris_server
solaris$ matlab -nosplash -nojvm
Welcome to Matlab v.
>>
The plot windows etc will still be rendered, but you do away with slowly pushing the entire GUI over the network.
If you don't open plot windows and things, you don't even need an X-server.
Connect with Putty or Cygwin from MS Windows, Terminal from OSX.
X11 forwarding on Mac: try 'ssh -Y solaris_server'
(... after installing X11 from the OSX install DVD
Mathematica replacement: http://maxima.sourceforge.net/ [sourceforge.net]
If you have a problem with The Mathworks or Wolfram's license terms, I suggest you take it up with them BEFORE buying their product and agreeing to their terms. else take it up with the person at your university taking care of the purchasing decisions. It is really not their fault if you buy their product under known terms.
-- Happy user of Octave at home & in the field where the ML license server won't reach. Lots of kids buy the student ML edition, it is fully functional, not tied to a network server, and no longer array size limited these days.
Re:11 Years? (Score:4, Informative)
Re:That sucks too, but we have a winner. (Score:4, Informative)
That's an old argument, but for the sake of people who haven't heard it before, I will enter the debate again.
Lisp syntax is actually very beautiful for describing tree structures. And tree structures are very useful. For example, web pages have tree structures. And many types of relational data. And with the addition of references, trees can be used to describe graphs, and thus, all data and all relations. Oh! And lest I forget, computer programs!
Now, why would you want to describe your program like a tree? Why would you want _everything_ to start with an open paren, then have a bunch of child nodes (which could be simple words or numbers, or could also start with an open paren, etc.), and finish with a closing paren? What is the advantage of this over having a bunch of curly braces, commas, semicolons, and infix operators thrown in for variety?
Well, the advantage of Lisp syntax is that it is extremely regular. And this is good for analysis and transformations. And _that_ is what Lisp is all about.
In most languages, you write your program in some complex surface syntax, which is then run through a complicated parser. The parser converts it into a tree (hey...wasn't there something about trees before?), and the compiler then performs all kinds of transformations on that tree. Transformations that are relatively easy to describe on trees, but not so much on the surface syntax of the programming language - that's why you generate the parse tree. Of course, this all happens behind the scenes. But not so in Lisp. In Lisp, your program already _is_ a tree the way you wrote it down. A convenient format for performing (and understanding!) transformations to be performed on the source code. And this is something Lisp programmers do all the time, and something that is rarely seen outside Lisp.
I believe this is largely due to the difficulty of describing and understanding program transformations in other languages. Lisp has a very simple macro system; a macro takes a tree you wrote, and runs some Lisp code, and eventually returns a new tree. And then it is as if you had written that new tree instead of the old one. So, where in Java you will see code like...
x.setFoo(y.getFoo());
x.setBar(y.getBar());
x.setBaz(y.getBaz());
(copy-fields x y foo bar baz)
FileInputStream stream = new FileInputStream("filename");
try {
} finally {
stream.close();
}
(with-open-file (stream "filename")
; Do something with stream
)
As it happens, the macro in the second example happens to be part of Common Lisp's standard library and the one in the first example doesn't. Of course, it can easily be written. What the macros have in common, however, is that they allow you to do the same things that the Java snippets do, but with less code, less repetition, and fewer weird characters. I don't know how you can not find that beautiful.
Re:Well, if they ever become competitive to Matlab (Score:3, Informative)
The bare minimum for signal processing stuff:
MATLAB: $1900
Simulink: $3000
Signal Processing: $800
Signal Processing Blockset: $1000
Subtotal: $6,700
A few more helpful tools that almost every engineer can make use of, not very extravagant:
Control System Toolbox: $1000
Filter Design Toolbox: $1000
Subtotal now: $8,700
I do a lot of RF comms stuff, so the following are very useful for me:
Communications Toolbox: $1000
Communications Blockset: $1000
RF Blockset: $2000
RF Toolbox: $1000
Subtotal now: $13,700
Implementing algorithms in the real world almost always involves fixed-point computation, so:
Simulink Fixed Point: $1000
Fixed-Point Toolbox: $1000
Grand total: $15,700
In fact, if you look at the MathWorks product listing for each category:
MATLAB CATEGORIES:
Math & Optimization: $4,100
Statistics & Data Analysis: $9,800
Control System Design and Analysis: $6,700
Signal Processing and Communications: $7,800
Image Processing: $2,900
Test & Measurement: $4,900
Computational Biology: $4,000
Financial Modeling and Analysis: $5,500
Application Deployment: $5,200
Application Deployment Targets: $12,000 (.NET, Excel, and Java each are $4k)
Database Connectivity and Reporting: $1,500
SIMULINK CATEGORIES:
Fixed-point Modeling: $1,000
Event-based Modeling: $5,800
Physical Modeling: $11,000
Simulation Graphics: $1,700
Control System Design and Analysis: $4,000
Signal Processing and Communications: $5,000
Code Generation: $30,300
PC-Based Rapid Control Prototyping and HIL: $10,000
Embedded Targets: $12,000 (Each processor is $3k apiece)
Verification, Validation, and Testing: $9,000
Find their product price list here:
http://www.mathworks.com/store/default.do [mathworks.com]
And you can add up what they recommend for signal processing applications yourself (Hint: just getting the recommended Matlab, Simulink, and Real-Time Workshop is $12,400.)
http://www.mathworks.com/applications/dsp_comm/products.html [mathworks.com]
They have recommendations for other fields of R&D also if you want to look.
Wow, I can't see how ANYONE could POSSIBLY rack up a $15k MathWorks bill. My educated guess is that you are not a moron, but that you are uninformed about more than just the moron status of this guy's "math guy." Maybe you got a very nice academic discount. Maybe you just got Matlab and a couple of toolboxes. But that's not the situation a lot of folks face when they actually want to accomplish something with Matlab/Simulink.
Re:11 Years? (Score:3, Informative)
This is the reason that we run Octave (Score:3, Informative)
OK, I'll tell you. (Score:3, Informative)
The open source model is all about market efficiencies. The closed source model is all about individual companies beating the market by differentiating their products. Open source makes software functionality a service you can buy, and that service is in effect a commodity. Pork bellies don't disappear because a particular slaughterhouse stops producing them.
In this case, you have another case of market efficiencies. There aren't enough people demanding a fully functional or compatible open source version of MATLAB on one hand, or programmers capable of contributing to such a product on the other, to produce the product on short order. If a commercial outfit was working on this, they'd hire people to produce it who otherwise wouldn't work on the product. They'd then have to sell the product against MATLAB, which they can only do by offering new features or lower prices. However they're very unlikely to be able to price it lower, since MATLAB's development costs are already recovered. So they add features. MATLAB comes out with its own incompatible versions of the same features, trims its price a bit, and competitor goes out of business.
All the money used to create the closed source alternative might as well have been piled up and burned. There is no value delivered to the market by the failed project. The vendor might as well have picked their customers' pockets for all the value the delivered to them in the end.
By comparison, an open source project taking a long time is a model of efficiency. It is not obvious to most people that an open source MATLAB is the highest use of their resources, therefore the project doesn't get that much resources. However it still produces value: users who don't need the missing features can use whatever is there. Developers on other projects can use the source code (subject to license) or even embed the entire product.
So, rather than rapidly consuming large quantities of resources to produce zero value, the open source model here is consuming small quantities of resources to steadily produce modest quantities of value.