I use Octave everyday for my business and I absolutely love it. I have a background in Matlab (and I still have a student version someplace) but turned to Scilab and then Octave to do audio signal processing. It's a fantastic package and you can't beat the price, but if you want to use it as a Matlab alternative there are couple of gotcha's that I ran into:
- the plotting using gnuplot is not as flexible as Matlab's plotting, although it is getting there
- in an attempt to steer clear of copyright issues (I presume) many (most? all?) of the mathematical functions have been written from scratch, and while they typically use the same references as Matlab functions, Octave functions may give slightly different answers than their Matlab counterparts. If you need 100% compatablity with Matlab, make sure to do plenty of testing first.
I must admit... I switched exclusively to Numpy / Scipy / Matplotlib about 3 years ago and never looked back. The power, flexibility, and extensive developer libraries offered by Python are unmatched (IMHO).
Oh, and for anyone who would like to try out vector computation on a GPU (eg. CUDA), you should check out the Theano project (a symbolic math library that can offload execution to the GPU): http://deeplearning.net/software/theano/introduction.html
I love scipy, ... except for zero based indexing. I might not be as bright as some, but I hated always figuring out "If I have a set of ten items, the index is from 0 to 9". Zero indexing is also NOT how real math is written in textbooks. C uses zero indexing because DOES describe byte offsets really well. In octave/ matlab the for looops are a lot easier to think about.
All in all, octave is quickly becoming a very viable alternative to Matlab.
> The GPL is sometimes a problem for commercial users of Octave or other free software.
<obligatory-GPL-comprehension-nitpicking>
GPL is never a problem for users. The GPL is a problem for rogue developers who might want to extend (or just rename, or not even that) Octave, close off the source code and then themselves start posing a (licensing) problem for users of the extended Octave version. But that is OK, since the GPL was designed to pose a problem for code closers and problem makers in the first place. Thanks for reading.
I think they mean is that the GPL can restrict the ways developers can combine various components. Ultimately software is developed for users, and if developers can't build software for their users, then the license can become a problem.
Sony, Nintendo (and others) solved this by running the said applications externally.
For example a Sony or Nintendo SDK would have the gcc compilers, linkers, bintools, etc, and they would distribute the source... Yet nothing stops them from writing pre-linker, post-linker, pre-compiler, post-compiler steps that would be required by the developer to get called (or get called automatically by a tool).
In such case you mix well GNU (GPL) with closed commercial software, and distribute the end product just fine.
You have to be extremely careful in a mixed license setup. Lots of folks make the mistake of linking to GPL'd libraries, thinking it's like the LGPL.
But yeah, external calls seem to be the safest bet right now, even if it isn't always the most optimal solution.
(e.g. you can often use GPL'd components by writing a server wrapper around them and communicating from your non-GPL code via network communications for example, an arbitrary, and silly distinction from just linking in the components and using message passing, but hey...apparently that's what freedom (as in free, not as in beer) is all about).
Also the different version of the GPL are incompatible with each other. For example, you cannot distribute combinations of GPLv2 and GPLv3 works. The recommended way to deal with this is to add the optional (but not default) "or any later version". Then the user can promote the license to be compatible. e.g. GPLv2+ is compatible with GPLv3.
I think you're describing aggregation which the GPL does not consider a derived work. Mere use of a GPL-licensed executable does not extend the GPLs terms to what you are doing (e.g. shell scripts, system() calls, etc). For each binary, the license terms of each statically or dynamically linked component must be simultaneously satisfied. The GPL includes a "system library" exception that excludes libraries shipped with the OS from that calculus.
The situation with combining interpreter code that doesn't access compiled libraries (e.g. pure octave M-files, or python code) isn't really clear to me. The FSF's opinion has been that a script that uses GPL'd interpreter code is subject to the terms of the GPL. I personally accept that interpretation out of deference to the FSF, but I've never understood specifically how that conclusion arises from the text of the GPL.
I do all my DSP algorithm research in Octave, because the price of MATLAB is just too high. I think I'm looking at somewhere on the order of $4k for a single license to obtain the signal processing stuff that I need in addition to the core license.
Would I prefer to have more graphing options, and some assurance that researchers' MATLAB code will work out of the box? Of course!
That said, Octave gets me really close for a fraction of the price. Also, I can peek inside the Octave source and get an idea of how the underlying routines work.
I've been using it for exactly the same purpose. When I think about how much it would cost me to get the Matlab equivalents I feel like sending the developers some flowers.
Python/Numpy works pretty well for this sort of thing too though, and the graphing features seem a little more sophisticated.
I've always wanted to try Numpy for this purpose, but I get exposed to so much MATLAB code in research papers for DSP that it hardly seems worthwhile.
Furthermore, I've built an entire Objective-C math framework (https://bitbucket.org/liscio/smugmath) that operates very similarly to MATLAB (i.e. vector-oriented) and allows me to easily translate DSP algorithms found in research papers over to shipping products (http://capoapp.com, http://fuzzmeasure.com).
And yeah, since Matlab is pretty much the standard it's a big plus to be able to use code from papers etc directly in Octave. Translating to Numpy is usually straightforward but it's definitely an extra step.
Numpy becomes very nice when you need to do some more general-purpose coding along with your numerical stuff though.
> Numpy becomes very nice when you need to do some more general-purpose coding along with your numerical stuff though.
Once you get used to "cell arrays" and "structs" and "struct arrays", you can do most anything in Octave that you can in Python, but the weirdness of those syntaxes is quite off putting for a lot of coders.
I work in finance, and Matlab is used a lot here. I work mostly with Python/NumPy/SciPy/SimPy stack so I do not have a lot of first-hand experience. But from what I am hearing from my peers, their problems with Octave boil down to mostly two things:
1. Small incompatibilities, that make your life more complicated when you exchange Matlab code and/or maintain other people's code.
2. Lack of alternatives to specialized toolboxes, like Simulink, statistical or financial packages etc.
WRT to incompatibilities, it would be great for Octave if they could file bug reports.
WRT to packages/ toolboxes, Octave and Octave Forge have not quite reached maturity, and there is ongoing debate about how to do that.
WRT to Simulink,... that is such a specialized graphical thing, I don't think it is coming down the pike any time soon. Somebody else mentioned an alternative...
I cannot possible recommend sage enough. I used it in every math and statistics class that I took in school and hacked on it a little towards the end of college.
To be completely cross-compatible with MATLAB, Octave would need to support classes. This makes it incompatible with class-using MATLAB libraries like PRTOOLS.
Otherwise I'd just stick to scipy, there are so much more python libraries out there, plus you get to use matplotlib!
The main reason to use Octave over Scipy is direct compatibility with Matlab code. Installation may also be a hair easier (I'm not sure on this point)
As someone who switched from Matlab (student license) to Scipy, I've come to the conclusion that Octave is a solution to the wrong problem. While non-student Matlab licenses are expensive, Matlab itself is also a crufty language that, once you exceed its core domain of "problems that only require (or can easily be represented as) N-dimensional arrays", quickly tends to spiral out of control. I've had this happen to me. Python, on the other hand, is a language that is already quite elegant, and the Scipy packages can allow for almost-verbatim translation of some Matlab code, but without losing a lot of other power and flexibility.
Remember that MATLAB started life as an interpreter written in FORTRAN for doing matrix maths interactively. It's a little unfair to compare it to something that came much later. The guys at Mathworks could have written an all-new language as good as Python (or embedded a language like Tcl or Scheme) at any time - they chose to retain backwards compatibility instead. That may be the wrong call aesthetically or technically, but I bet it was the right call commercially.
> It's a little unfair to compare it [MATLAB] to something that came much later.
You're certainly right that's it's not really a fair fight between the languages. WRT Octave, though, anyone for whom a MATLAB license is too expensive probably doesn't have the mountain of legacy code that would be required for me to justify staying with a technically and aesthetically less pleasant language.
For me the biggest draws are a syntax that is closer to numerics and the C++ API for extensions. Scipy code looks clunky to me with a lot of distracting and irrelevant characters, but I'm probably just not used to it. Another difference is that Octave uses pass-by-value semantics with a copy-on-write implementation whereas I think scipy uses pass-by-reference. There are pros and cons to both approaches. I think in interactive use Octave is better able to recover from errors without trashing your data which is nice for quick calculations.
I started using IDL at one point (the facility used it) and hated the syntax--but, I will say that their licensing was cheap. Then, I moved to Matlab and ran into problems building maintainable code (to be fair, I think things improved after Matlab 7) and with exchanging code with people who did not have access to all of the toolboxes (want to optimize a function--that will be another few thousand dollars....Want to do a bit of DSP....). Also, in fairness, their editor is rather nice--so is the JIT) So, to build code that I could exchange (and to do GUI building, etc) I switched to primarily to the python/numpy/scipy/matplotlib stack. Somehow, I passed over octave....I would recommend numpy/scipy/matplotlib. The plots are in matplotlib are excellent and the community is very friendly. Also, with numpy, I can do array processing very quickly. Finally, if you need to build an app, then you can make a GUI, or provide a webservice. Finally, you can play with libraries such as CUDA and bind them to python if your project needs it.
It is a bit of a pity to see the effort split between two huge projects with roughly the same goal. Anyone has any ideas why it is so? or is it like a vim vs emacs(i.e. quasi religious) issue?
They're really old projects both starting around 1990. Scilab was not free software (commercial distribution of modified Scilab was verboten) until they switched licenses to CeCiLL with Scilab v5 (2008?) which is a FSF recognized free software license and GPL compatible.
Unlike Octave, Scilab's goal is not compatibility with Matlab. Unmodified Matlab code will not run in Scilab. One of the goals of octave is to run Matlab-compatible code. Scilab has a comparatively limited syntax relative to Matlab and Octave. Octave's syntax is more expressive than Matlab's but currently lacks the new classdef OOP (Octave does have @class OOP) . The last time I checked Scilab didn't seem to have any OOP.
There is always some overlap between these types of software, but R and Octave are fundamentally different products. R is a statistical tool, while Octave is a numerical analysis tool. Depending on the problem you're trying to solve, you may find one or the other to be more convenient.
Pretty much. There's actually quite a bit of overlap between the two. If you're doing statistical work then R is a natural. For engineering tasks Octave/Matlab is more convenient, particularly if you're doing a lot of linear algebra, where Octave's syntax is ideal. You'll also find more third-party code available if you stick to the language closest to your problem domain.
R's graphing facilities are superb though, and easily outdistance Octave's. So if you want to build complex visualizations that might trump other concerns.
Numpy/Scipy can do most of what R and Octave can do but their syntax isn't optimal, since they're built on a general-purpose language.
I would call R 'Matlab for statisticians'. They're similar in that they are matrix-oriented scripting languages. The main difference is their focus, which matters mainly in regards to what kind of libraries you'll find for either.
Tried it. Not even close to a MATLAB replacement even for students. It doesn't support or doesn't name half of the statistical functions the same thing, which makes it useless for problem sets (where you have to turn in your source code).
No, often the code is slightly different and doesn't run correctly in MATLAB. The last time I tried was December for probabilistic signals and random signals. I'm the student so the problem wasn't me, it was the TA's who ran the code and gave you a perfect score if it ran and produced exactly the same results or a zero if it didn't produce the same results.
Personally, I use sci/numpy for all of my statistics/numerical analysis needs.
Maxima which is a direct decedent( I think they even share code now) of Macsyma one of the first symbolic math packages developed at MIT. Wolfram was inspired by it when he created Mathematica. In fact I think it was because he despised macsyma (cause it was in lisp and not C I believe, there are some mailing list post describing the events) that he decided to create Mathematica. So the enemy of your enemy is your friend ;p
You might try sympy (a python project)--the community is very responsive. But, be prepared to get your hands dirty if there are some features that aren't present yet.
- the plotting using gnuplot is not as flexible as Matlab's plotting, although it is getting there
- in an attempt to steer clear of copyright issues (I presume) many (most? all?) of the mathematical functions have been written from scratch, and while they typically use the same references as Matlab functions, Octave functions may give slightly different answers than their Matlab counterparts. If you need 100% compatablity with Matlab, make sure to do plenty of testing first.