Slashdot Mirror
GNU Octave 3.0 Released After 11 Years
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."
For a lot of projects, the major number indicates binary compatibility.
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.
I have been using Octave heavily over the past few years (and done a little light development), and I can say for certain that development is accelerating. In the last few years, there have been several new large contributors. One of them has made significant improvements to getting the bleeding edge Octave running with all the bells and whistles and installers on Windows, another dedicated to putting out binaries for Macs. All the core distributions have fully optimized Octave packages available. Most of the handle graphics compatibility has been done in the last 12 months. I know there is a push by people who are not the core developers to make an IDE (some based on Eclipse, others on GtkSourceView/VTE, others on QT). There has been work to make the debugger better. I guess my point is that a lot of project like this can take time to develop critical mass and that I think Octave is well on its way. Just as an aside, I think the design and implementation of Octave is great. It is the first kindof big open source project that I have really been able to wrap my head around in terms of understanding the code base and where things are/how to hack on it.
Define not "not treating customers well."
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.
Or windows users for that matter. There are plenty of X servers out there for Windows including Xming. Putty even has an option for X11 forwarding, so no one can really argue that its remotely difficult to set up.
No, he isn't lying.
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?
Or Windows users, for that matter. The Xmingw X server works pretty well on Windows, and if you are allergic to free software (after all, I don't see why anyone would be using Windows otherwise), Hummingbird makes an X server.
``The LISP guy has a point, though that syntax is even uglier.''
...in Lisp you will see something like...
...which will be transformed into the code that actually does the copying. And where in Java you will see...
// Do something with stream // Make sure stream is closed, even if an exception was thrown ...in Lisp you will see...
...which is a macro that expands into the appropriate code.
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.
Please correct me if I got my facts wrong.