Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Software Science

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

GNU Octave 3.0 Released After 11 Years

Comments Filter:
  • 11 Years? (Score:2, Interesting)

    by Anonymous Coward on Saturday December 22, 2007 @07:25PM (#21793782)
    11 Years no GUI, and no JIT and only partial MATLAB support. Tell me again why GNU FreeSoftware is a better development model if you don't mind.
  • by coryking ( 104614 ) * on Saturday December 22, 2007 @08:47PM (#21794216) Homepage Journal
    But it was under development the whole time.

    I know some people might disagree with me, but I'm beginning to think some open source projects would benefit from using a year for the public version number:

    Octave 2008 (3.0.x)
    Thunderbird 2006 (2.0.x)
    Firefox 2008 (3.0.x)

    FreeBSD 2006 (6.0)
    FreeBSD 2008 (7.0)

    PostgreSQL 2006 (8.1)
    PostgreSQL 2007 (8.2)
    PostgreSQL 2008 (8.3)

    While internally, the product could use the same version scheme it did before, I think many open source projects are far too anal about version numbers. The stubborn refusal to bump up the "big" version field doesn't help public image because if it never moves up people think the project is dead.

    The only version number that matters is the build number and repository version, the rest is marketing. Granted the year scheme isn't perfect in the early stages of a product when functionality is drastically changing every 3 months, but on mature products, I think we could all really benefit from number schemes that use the year the product was release.
  • cat gack (Score:3, Interesting)

    by epine ( 68316 ) on Saturday December 22, 2007 @09:35PM (#21794468)
    I was trying to preview my markup for this post, the preview function refused to work with a blank subject line, insulting me with "cat got your tongue?" so I'm posting under my working title.

    Math software shows up here fairly regularly. I keep taking notes, but never get around to using any. The R statistical package also gets frequent good mention, which I understand is accessible from within Sage.

    Where does Octave stand relative to Sage?
  • by Anonymous Coward on Saturday December 22, 2007 @11:04PM (#21794948)
    > Define not "not treating customers well."

    OK, I'll define it for you.

    I have been a Matlab user since my first graduate classes in control systems in the early nineties, when it ran on old PCs in our controls labs and didn't have the current integrated GUI. It was a revelation to be able to perform matrix and control system analyses in such a simple way, with the many built-in functions (lsim, step, bode, margin, etc.) There was nothing else like it and it taught me a lot.

    In my subsequent work as a controls engineer in the astronomy field, I have used Matlab consistently for many years, occasionally requesting technical support - as you mention - and normally getting a good response. I have downloaded free evaluations of new toolboxes and sometimes we have followed up with a purchase, if the product is worth it. We use Simulink a lot for design, and this is also a really good tool.

    Over the last two years or so, Matlab - the company - has been getting more unfriendly. When I decided not to renew my ongoing 'maintenance' package with them, after I saw we were getting poor value for money per year (a few .x.x upgrades for more than a thousand US dollars a year), I received several of the usual reminders to renew, followed by a very strange email:

    "September 25, 2006

    Dear Mr. (Name Deleted):

    (Company Name Deleted) is a valued customer of The MathWorks, Inc. and we appreciate your business. As you are probably aware from reading press and industry reports, software license compliance remains a challenge for the computer software industry. Like many of our peer companies, The MathWorks is implementing a license compliance audit process and has engaged an independent third-party auditing firm to assist us in performing this work.

    This letter does not indicate that your company has been selected for an audit, but rather, serves as a general announcement of the program. While we are in the planning stages of the program, we wanted to take the opportunity to inform you of this activity. We realize it is very important to answer any questions you may have about the program and we want to work hard to eliminate any surprise if your company does get selected for review.

    As we move forward with our program, we will begin to select various customers to conduct compliance audits pursuant to the terms of our software licensing agreement. If your company is selected, you will be notified in advance by a representative of The MathWorks. Our auditors will then contact your company to discuss the audit timing and procedures, and request documents to help make the process run as efficiently as possible.

    The procedures our auditors will follow are designed to validate software licenses deployed and measure deployment against historical records. We understand that you are busy and every step will be taken to minimize the impact to your daily operations during the process.

    If you have questions about your current usage of MathWorks products, please do not hesitate to contact the Installation and Licensing Team by e-mailing: support@mathworks.com

    We value our relationship with your organization and look forward to your support.

    Sincerely,

    The MathWorks Licensing Compliance Team

    To update your address, send e-mail to: service@mathworks.com

    The MathWorks, Inc. - 3 Apple Hill Drive, Natick, MA 01760 - 508-647-7000"

    I never heard more about this, but it looked suspiciously like applying a bit of pressure - 'if you don't want a visit - or the possibility of one - from our licensing compliance goons, why not just cough up that maintenance fee'. I mean, if piracy and so on is such an issue, then check out every single customer, irrespective of their maintenance status. What have you got to hide, eh?

    What finally pissed me off was when I wanted to download a trial of a toolbox I was interested in purchasing. Here is the friendly reply:

    "(Name Deleted),

    Here is a quote to add the (Toolb
  • Re:11 Years? (Score:4, Interesting)

    by betterunixthanunix ( 980855 ) on Saturday December 22, 2007 @11:30PM (#21795056)
    While I know that MacOS X ships with an X server, I have met only one Apple user so far who has set it up, and beyond that, none of the rest are even aware of X11. X11 is not enabled by default. The Apple users I've encountered have very little knowledge of X11, ssh, forwarding, non-Apple Unixes, or how a program can run on one computer and be displayed on another. Apple designed a GUI-centric OS, and its users are often loathe to open a shell and start typing in commands (considered to be too "unintuitive"), at least in my experience.

    Most Linux or BSD users, who happen to be using a GUI, will already have X11 running, and will therefore have a much easier time running Matlab off our Unix servers. There is certainly no problem running an X server in MacOS, nor is there a problem running it in Windows -- but these systems are not being marketed to people who have the technical skill to set that up. Not to start a flame war, but Apple just isn't trying to attract users who are aware of X11, Unix terminals, programming, etc. If anything, Apple has tried as hard as possible to remove the "nerdiness" from computing, and present there systems as intuitive, simple, straightforward computers that any idiot with no computing skills whatsoever can figure out how to use. That's fine, but when it comes to doing something that doesn't fit into the desktop computer model -- running a program on a server, and having its GUI rendered on your PC does not fit into the desktop model, at least not as Apple has implemented it -- they are not marketing to people who are comfortable, knowledgeable, or appreciative of such things. You don't have to be their target market to use Apple systems, but you have to be aware of what their target market is, and that the overwhelming majority of Apple users have no interest in anything beyond the desktop metaphor that Apple has created.

    It is necessary for me to stress that I am not criticizing Apple or its users; I am criticizing my university and the Mathworks company, for creating an environment where only people who are involved in computing can access Matlab outside of our computer labs. My point is that, because of the terms of Mathworks' site license, the software must be on a specific number of university owned systems, and that while there is nothing stopping Apple or Microsoft users from accessing that software, the majority are not knowledgeable enough to do that. The university doesn't do much to educate or encourage students to set up X servers and run Matlab/Mathematica/Maple on our servers (can't say I blame them; the increased network and server load would probably bring everything to a grinding halt), and most students who use this software aren't even aware that they can access it in that manner anyway.

  • by datan ( 659165 ) on Saturday December 22, 2007 @11:51PM (#21795224) Homepage
    about your first point regarding the audit letter--it may or may not simply be a coincidence.
    but your second point you definitely have no grounds to complain. They allow only people who are on software maintenance to have a free trial of the toolboxes. That's one of the benefits of software maintenance. "we were getting poor value for money per year (a few .x.x upgrades for more than a thousand US dollars a year), " -- you're forgetting the ability to download free trials of toolboxes. If you need any technical support you're entitled to a certain xx hours per year.
  • by steve_bedrick ( 715622 ) on Saturday December 22, 2007 @11:54PM (#21795240) Homepage
    I bought a license for Matlab for my old PowerPC-based PowerBook about a year ago, and was initially quite pleased with Mathworks- the times I had to call them for support, they were helpful and responsive. All that changed when I switched to an Intel-based Mac a month or so ago. While moving all of my software over to my new laptop, I observed that most software companies used one of two possible approaches to the software redistribution problem:
    1. Release an Intel-compatible binary of their product, and make it available to current license-holders free of charge; or
    2. Take advantage of the opportunity to do a new major-version revision of their product, which license-holders would have to pay to upgrade to.

    Each of these, to me, seem like reasonable solutions— if it's a major-version update, I'd have to pay for it anyway... and if it's just a recompiled version of the product I already have, it should be free to current users. It turns out, however, that there was a third possibility, which is what Mathworks chose:

    3. Release a new minor-version Universal Binary update, and then make all current customers buy a new full-price license in order to get it.

    So, in order to run Matlab on an Intel-based Mac, current PowerPC license holders have to re-purchase their expensive software from scratch. No upgrade path, no nothing— just a nice, loud, "screw you" from Mathworks to their users. And it's not like we could just use our PowerPC verisons under Rosetta- there was a workaround, but it involved disabling all of the graphing/visualization features. Basically, it was a "pay for a full new license or don't use Matlab on your new computer" kind of thing.

    I dunno, maybe it's not that big of a deal, but it still felt pretty crappy. From a customer service standpoint, it wasn't exactly a master-stroke- it wouldn't have really cost them anything just to let current license-holders have an Intel-compatible copy of the software they'd already paid for...

  • Re:Good and bad news (Score:4, Interesting)

    by RAMMS+EIN ( 578166 ) on Sunday December 23, 2007 @01:55AM (#21795862) Homepage Journal
    ``But this project kind of supports the idea that open source can't really innovate, only follow (sometimes far) behind what proprietary companies invent.''

    I don't know how _one_ open source project copying a proprietary project is supposed to support the idea that open source as a whole can't really innovate. Reasoning that way is completely bogus.

    ``It would have been really interesting to see what some of the open source folks could do if their goal was to surpass MATLAB instead of be an almost-free version that's almost as good as something that people almost like to use.''

    I agree with you, and a lot of open source development does exactly that. Or implements things that there is no proprietary software for. But Octave, like a lot of other GNU software, has a different goal, apparently: allowing users to take their MATLAB code and run it using only Free software. That's a worthwhile goal, too. Although it's not something I'm personally interested in - and, apparently, not something many people are interested in at all, or progress would be quicker (either in Octave or in a sister project fueled by developers who resent Octave's slow progress).
  • SciPy (Score:2, Interesting)

    by nguy ( 1207026 ) on Sunday December 23, 2007 @07:58AM (#21796966)
    Octave is a great effort, and it is very useful for being able to be able to run Matlab code freely. However, most of the effort in open source numerical computing is happening with NumPy and SciPy (www.scipy.org). For most applications, SciPy is already far superior to even the commercial version of Matlab, and SciPy is the de-facto standard in several scientific communities. There are a few areas where Matlab still has toolboxes that have no good equivalent for SciPy yet, but that's going to get fixed.

    So, if you're looking for an open source Matlab alternative, use SciPy [scipy.org] for new development and stick to Octave only for occasional backwards compatibility and testing during porting.
  • by edwinolson ( 116413 ) on Sunday December 23, 2007 @08:54AM (#21797134) Homepage
    I think that Matlab's biggest strength is how it easy it is to visualize and manipulate plots. Matlab plots can be easily tweaked, enough so that they can be used as figures in academic papers. In contrast, Octave's previous use of gnuplot always felt clunky-- it was hard to get it to do exactly what you wanted, and the results were often ugly.

    I will check out Octave 3's improved "graphics handle" support-- I hope it closes the gap. But for my own part, I care much less about language compatibility and more about making it really easy to visualize and explore your data.

    -Ed
  • gnuplot (Score:1, Interesting)

    by educated_foo ( 93255 ) on Sunday December 23, 2007 @11:15AM (#21797930)
    Octave is a great piece of software, but it has been going downhill for awhile. It used to be that you could make nice plots via gnuplot commands, but for some reason the project leaders insist on sabotaging this feature.
  • by RAMMS+EIN ( 578166 ) on Sunday December 23, 2007 @01:23PM (#21798746) Homepage Journal
    At first, I was going to ignore your comment as completely idiotic, but looking at some of your other posts I found a few good ones, so I feel you deserve a good answer.

    ``the way they always trot out the same "with-foo" example. Yeah, it's a minor syntactic improvement over try/finally, but can't you think of something else?''

    First of all: obviously I not only can, but _did_ think of something else; it's right in the very same post.

    Secondly, I don't agree that with-open-file is just "a minor syntactic improvement over try/finally". It opens the file _and_ makes sure the file is closed no matter what. It does the right thing in case an exception occurs, but, more importantly, you can't forget to write code to close the file...because you don't have to write anything more.

    Thirdly, I'd like to turn the "can't you think of something else?" around and turn it into an argument in favor of macros, instead of a baseless ad hominem. The beauty with macros is that they give you a very powerful abstraction mechanism. So that when you _do_ think of something else, you can implement that. Show me how to do the first example from my earlier post without macros. I can give you more examples of cases where macros are or would have been very helpful, but I'm not going to spend the time unless I am convinced you are actually interseted in learning, rather than bashing macro advocates for no reason I can fathom.
  • by educated_foo ( 93255 ) on Monday December 24, 2007 @10:48PM (#21811626)
    Well... thanks for the careful response. I guess I don't think Slashdot is a place to learn anything -- nonspecific online technical fora are flame-scorched wastelands -- but I'll try to be civil.

    I missed your other example, which is not clichéd like with-foo. However, it doesn't require macros in a non-broken language:

    sub copy_fields {
    my ($x, $y) = splice @_, 0, 2;
    $x->$_($y->$_) for @_;
    }
    Similarly, with-foo is usually written with a lambda rather than with macros in Scheme. Don't get me wrong -- I think macros are cool and useful. What I'm saying is that most examples fall into one of a few categories, and these are often well-served by other mechanisms (lambdas) or special syntax (decorators). Uses of macros that don't have non-trivial macro-free alternatives are harder to think of.
  • by RAMMS+EIN ( 578166 ) on Tuesday December 25, 2007 @07:28AM (#21813772) Homepage Journal
    Good job. That post shows that you are actually interested in getting things right, and not just in perpetrating whatever idea you have no matter what the facts are. It also shows you know what you're talking about. I am happy I decided to reply to your original post, and I apologize for the strong language I used.

    Now I will nitpick a bit, for the benefit of people reading this thread (yeah, right ;-) ) who want to have a more complete understanding of what is going on. It took me a bit to understand your code (which is very elegant, by the way), but what I eventually got was this (first repeating the code for completeness):

    sub copy_fields {
    my ($x, $y) = splice @_, 0, 2;
    $x->$_($y->$_) for @_;
    }

    This is a function which, when called, will assign its first argument to $x and its second argument to $y. It will then iterate over the rest of the arguments, and, for each argument, use it as a property on the object in $x and the object in $y, assigning the value of that property of $y to the identically-named property on $x.

    So, when you call the function like copy_fields($a, $b, 'firstname', 'lastname', 'birthday'); (I hope passing the field names as strings is the right way to do it in Perl; I'm not a Perl hacker), you will end up with $a->firstname being the same as $b->firstname, $a->lastname the same as $b->lastname, and $a->birthday the same as $b->birthday.

    In Common Lisp, you can write code that does exactly the same thing. For example,

    (defun copy-fields-function (x y &rest fields)
    (loop for field in fields
    do (setf (slot-value x field) (slot-value y field))))

    You can then call this function like (copy-fields-function a b 'firstname 'lastname 'birthday) and get the named fields from b copied to a, just like in the Perl code above.

    The above code uses regular functions (both in Perl and in Lisp). So, if copy-fields can be implemented as a normal function, why did I drag macros into this? Well, the difference between functions and macros lies in when things are evaluated.

    Astute readers will have noticed that the names of the fields in the call to copy-fields-function above have quotes in front of them, whereas the copy-fields in my original post [slashdot.org] took them without quotes. This is because, when you call a function, the arguments are evaluated first, and the values that result from that are passed to the function. So if you wrote (copy-fields-function a b firstname lastname birthday), you would be asking to pass the _values_ assigned to firstname, lastname, and birthday into the function, which would likely result in an error. Instead, putting quotes in front of the symbols causes the symbols themselves to be passed to the function, which is what you want in this case. (Without the quotes, the equivalent call to the Perl version would be copy_fields($a, $b, $firstname, $lastname, $birthday);).

    By contrast, arguments to macros are always passed to the macro as written, without evaluating them first. This is what allows macros to perform transformations on source code. Functions cannot do this, because, by the time the function actually gets to do anything, all its arguments will have been evaluated already. And this is an essential point, because it means that macros can control order of evaluation. The source code given as an argument to a macro may be evaluated once, more than once, or not at all. Thus, you can use macros to implement control structures, like conditionals, loops, pattern matching, etc. Or lazy evaluation. Or object systems. Macros allow you to extend the language...without having to modify the compiler. That's a lot of power for a single construct.

    Another thing to mention is that, whereas functions (at least semantically) do their work

"Summit meetings tend to be like panda matings. The expectations are always high, and the results usually disappointing." -- Robert Orben

Working...