GNU Octave: A high-level interactive language for numerical computations [pdf]
octave.org
octave.org
It's very hard to recommend that students and colleagues grow invested in toolchains involving proprietary software that they may not reliably be able to afford/activate/use in the future, particularly when some students may end up working in developing nations.
Here's hoping that someday, Octave does to MATLAB what R has done to SPSS and SAS. MATLAB is a dinosaur deeply begging for an asteroid.
The future is here. As a research student in a developed nation, it's very annoying to deal with MATLAB projects. Our lab has a fairly strict no-new-code-written-in-MATLAB policy. Getting a personal licence is fairly straightforward as a student (for now), but running it on a cluster, or anything beyond my personal computer is very annoying.
And cluster computing in MATLAB, I agree, is just that: a cluster.
Additionally I've not found a plotting solution that is as robust and fast as MATLAB.
MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.
Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..
With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understanding of how it works. Thankfully, people are willing to help you tweak your code to make it much faster.
Overall I'm excited for Julia, but have a lot to learn. As far as Octave/Scilab type applications go, I find them useful for small systems where I need to make sure the math of what I'm doing is correct before writing it in something like Julia or Python + Numpy. Excel is also surprisingly good for the really simple stuff (Ex: inverting a small matrix and doing some matrix multiplications).
A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now.
In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm.
On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba).
[1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...
https://github.com/JuliaLang/julia/issues/4373
Starting all of Matlab never took that long.
Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are actually writing code (i.e. grad students) don't mind the syntax because they learned it in school starting in undergrad.
Octave's main appeal to me (and most people I work with) is being able to run existing MATLAB code. However, making it work for nontrivial MATLAB projects, is, well, nontrivial. It's also very slow.
Julia is the language I'm most excited about. It's fast [1] even though it has a slow startup time, and that's improving quickly. It's got a nice grammar-of-graphics-based plotting library [2] that's quickly catching up to R's ggplot2. I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future). I like the syntax a lot, too. The data types take some getting used to, not unlike R. I also think if Julia moves away from JIT compilation, it has potential to be the language of choice for deployed NN models (right now, that's C++).
As for plotting, R's ggplot2 beats MATLAB any day of the week for me. To each his own.
I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler
They've been conducting several outreach programs to move academics and students off expensive and proprietary (and therefore often pirated) software to free alternatives (mostly around the Python ecosystem).
The project is quite successful from what I know.
But all this niceness means really that the software is more in the realm of spreadsheets than standard programming languages. Maintenance is guaranteed to be a nightmare and conversion to an actual programming language similarly.
The problem is that there can't be any small way to get off the beast. Because Matlab isn't a language but a rag-bag of features, nothing can be compatible with it. Indeed, you could be 100% compatible today and wake up incompatible tomorrow. It's position is like that of the monster desktop applications like Excel, Adobe Creative Suit and other nightmare abominations.
"You may think you're being productive but really, you are just feeling a rush from the grade cocaine of technical dept"
MATLAB is a tool for research, not engineering. In research, you check hypotheses; you write a lot of throwaway code. The 0.1% of validated models that end up in production can be rewritten in other languages, but nothing replaces the fast turnaround time of MATLAB. Or similarly organized R Studio.
Matlab integrates with SVN or GIT, you have got the functionality for unit-testing, proper debugging and profiling and namespaces through packages. OOP works also well although you will pay for it in performance. Additionally, you can easily use Java packages and interface with .NET and COM.
Compared to how R is used here, the whole Matlab environment feels much more complete and solid prototyping is certainly an advantage. Nevertheless, we feel the pain when it comes to datasets of 10-100 GB for which we don't want to set up a database. We haven't bought the Parallel toolbox and without this, processing is just very slow. Here R shines with e.g. data.table.
If I would rewrite the applications, I would however not do it in Matlab, because the audience of people looking at the code is more familiar with open source alternatives.
It won’t because all those new algorithms aren’t written in Octave (for the most part), but MATLAB (or Python or Julia).
MATLAB is not a dinosaur: it has had line profiler, JIT compiler, 3D plotting, builtin scriptable debugger in the default installation, long before Python or Julia, who still struggle with these highly valuable tools. Now it has notebooks, and plenty of other new stuff inspired by recent new stuff in Python et al. On top of that there is a Python FFI so you can call out to a Python installation if need be.
SPSS and SAS have horrible, horrible scripting languages. R is just ...slighly wonky. So as a language, R was a huge improvement on its alternatives. Whereas Octave is just a clone of the Matlab language, (almost) no improvement, just slower and less access to libraries.
With that being said, certain tasks (control systems is a big one) naturally map really well to Simulink because the graphical block-diagrams in Simulink are identical to how your teacher draws out the system on the blackboard.
To use an example, power systems texts might use Matlab to show the algorithms for transmission level powerflows (Newton-Raphson, Gauss-Seidel, Fast-Decoupled, DC), but they use Simulink to show how the control systems on a generator are modeled and you can easily inject an oscillation and plot out how it would impact the generator. You could of course model the control systems of the generator with regular code, but I think it would be far harder to reason about. I know Scilab has something called "xcos" or something like that which is the beginnings of a free Simulink competitor, but I haven't seen anything in Julia or Python that can do what Simulink can do. If someone knows how to best do controls work in Python or Julia, please let me know how.
I still have some old personal code left in matlab, and I have been using octave a bit lately just to keep running it- I have to say I do appreciate octave. My biggest complaint is how slow plotting is, for instance, I have a method of characteristics supersonic nozzle design software based on the modified Sauer method and methodology of Zucrow and Hoffman, that runs in a couple seconds, but in octave it takes several minutes to plot no more than a couple hundred lines (no, just straight lines with two points). What gives?
https://www.mathworks.com/pricing-licensing.html
which is around $2k, but then pay a yearly maintenance fee to get upgrades, which is vastly less.
This is one reason why if I had to pick commercial software I would choose Mathematica as they put everything in core as part of the standard license and don't require toolboxes for something the default software should have.
Now I use Python exclusively. The language is so much better and more sane and almost any library is available. I will never go back.
Today, I would recommend Matlab only in rare circumstances. Currently I cannot think of one use case that I had in the last three years where I would prefer Matlab to Python. Using the Matlab language with a portable Octave installation can be useful for teaching matrix/vector topics to people who have little programming experience and don't know Python. You can get results very quickly. The syntax feels most natural for manipulating matrices and everything seems to be a matrix.
Other than that I think the Matlab language and ecosystem is kind of a dead end. But it will provide profits for a few more decades due to sheer inertia.
The only thing I can see is as a way of running Matlab codes in clusters on cloud w/o having to also run the license servers.
1. I believe it to be far easier to debug an algorithm in MATLAB/Octave than Python. When I drop into the debugger, I can immediately check things like the eigenvalues of a matrix with a simple "eig(A)" or look at the sparsity visually with "spy(A)". Though this is possible in Python, I believe it to be far easier in MATLAB/Octave because the core mathematical functions are immediately available.
2. MATLAB/Octave link into the good factorization codes directly and provide license coverage in different ways. For example, both codes link into things like SuiteSparse, which gives access to fast Choleski and QR factorizations. These routines have different licenses, but the good ones are dual licensed GPL/Commercial. Octave links into the code under GPL licensing. MATLAB provides a commercial license. This means that I can give a customer MATLAB/Octave code and they can choose whether or not they want license coverage using MATLAB or to release the code under GPL and we don't run afoul with the licenses. Candidly, not having to go off and obtain a second license for SuiteSparse is nice.
3. In my opinion, the C-API in MATLAB/Octave is more sane than Python. It's not great, but the matrices are laid out in a rational method in MATLAB/Octave, so it's really, really easy to link into an old C/C++ or Fortran codes. Often, I've used this trick to debug the C/C++ code because I can more quickly visualize the matrices in MATLAB/Octave than I can using the native language.
As for the difference between MATLAB and Octave, I prefer Octave over MATLAB since:
1. Octave is more sane when dealing with the C-API. MATLAB is not bad, but it can be finicky sometimes and I don't feel like I should have to manually set dbmex on.
2. Octave uses the system version of GCC and does not package it's own. MATLAB does and for many years since MATLAB slow played their GCC version, this was a major annoyance when linking to codes that used C++11/14. MATLAB has done a good job in the last few years of catching up, but I still prefer to use the system compiler.
3. There are bugs in some of the Octave packages. MATLAB tends to have fewer such bugs. Most of the time, it doesn't matter till it does. Just file the bug with Octave. They can be slow, but there are a lot of people who volunteer their time and filing such bugs or helping to fix this is just the cost of this kind of software.
And, look, if you like Python, great. I also work with Python. However, again, for prototyping a technical algorithm, I prefer Octave.
I also use MATLAB/Octave quite a bit for numerical algorithm prototyping, and mostly hate it. The language has a shallow learning curve, true, but for complex software it gets ugly very fast. It’s just not a well designed language, and if you have any CS background that becomes very limiting.
The thing that MATLAB brings to the table is the incredibly high quality numerics toolboxes. Octave gets a few of those but far from all of them, making it in my experience a poor runner up.
Whenever I have a choice I now go first to Julia. The language just makes me happy and the numeric infrastructure is almost complete enough.
Except for something like Simulink. When you need Simulink, there’s nothing else out there that’s a valid alternative.
A language like Julia tries to bridge that gap. My problem with Julia is that we don't get license coverage for things like SuiteSparse even with a JuliaPro license. MATLAB has done a fantastic job of dealing with this and is well worth my license fee every year, so that my customers and I don't have to deal with it. Till this changes, it's a nonstarter for me.
As far as the differences in packages between MATLAB and Octave, I'll contend that it depends. For their lower level routines, they often use the exact same codes. Both use ARPACK for iterate eigenvalue solving. Both use various forms of SparseSuite, UMFPACK, LAPACK, and the like for their algebra. For me, I tend to only use these lower level routines, so there's little or no difference in performance or efficacy between the two. For the toolbox arena, I know there are differences and I agree that can be frustrating. I suppose my point is that it really depends where on the spectrum of lower level to higher level mathematical abstractions that we need. For low level abstractions, I feel that Octave works great and it's been a critical tool for me.
For simulation there is the Modelica standard for which open source implementations exist. But you don't code-generation for controllers, etc.
Should a university use something like Matlab/Octave or Python to teach numerical methods and related classes?
Matlab is usually only ~$20 for an engineering student and the language itself is mostly imperative with matrices as the default data type. Also, plotting and variable inspection are available as part of the default install.
Python is Object Oriented. While that is certainly better (well ...most would argue so) from a software engineering perspective, it is a bit of a hurdle for an engineering student with a little bit of C background. I can still remember most of my numerical methods homework assignments. Build this matrix, invert it, implement Simpson's method...blah blah. This is definitely possible in Python, but I would've had to figure out which libraries to import, which Python distribution to use (if you don't use Anaconda or WinPython, getting certain libraries to work is difficult), and a myriad of other problems.
In short, even though I like Python better, Matlab might have been a better choice by my teacher at the time which allowed us to focus on numerical methods and control systems rather than getting lost in the rich Python ecosystem which has a higher learning curve.
Does that mean Python couldn't have worked at all? No I don't buy that either, but think it requires a different approach. If I was the engineering Dean I would require a course called intro to scientific Python which is all about getting a good Anaconda distribution setup with the Spyder IDE and Jupyter Notebooks with some basic Python coding. Then, when it is time to take your numerical methods, digital signal processing, control systems...etc, the teacher can host Jupyter Notebooks that interactively explore the subject with LaTex, code-snippets, and graphs. There is a university somewhere where the professor has a full DSP book done via Jupyter Notebooks and it seems glorious.
Guess what, apparently the first hit is not always free. There are people posting in this thread who have to pay as much as 20k per year for a fully licensed Matlab.
2.) I've posted several comments on here including one showing that the cost can be up to $20k, so I'm well aware of that fact, but it is irrelevant to the above comment as the $20k is for working professionals and not poor engineering students where the cost is indeed ~$20 as I've paid it. Note that $20k is insane by some standards, but engineering software frequently gets much much higher than that. Yearly licenses in the 0.5 million range are common in my industry, so $20k is not considered unreasonable based on cost alone. It is unreasonable to me when they have free alternatives.
3.) I have said multiple times on here that I prefer Python and Julia as they are deeper and don't cost an arm and a leg. However, my above point still stands that Matlab isn't a bad solution for a student. There is some lock-in of course, but it isn't too bad to migrate away after you graduate and can no longer get the student rate.
I can't stress enough that what you buy with MATLAB is license coverage. Octave and Julia hook into many of the exact same libraries, but they have not negotiated a commercial license for things like linear system solvers. That means that distributed binaries may be subject to things like the GPL. If that's what you want, great. I like the GPL for a certain kind of software delivered to a certain kind of clientele. However, it's a nonstarter for most of my clients, so they buy MATLAB.
Is this a nuisance also for you? I would be interest in how do you overcome this (asking for a friend working in image processing in MATLAB)
I recall there being some minor differences in how mex files are written, but I'm looking now and all the routines I typically use are mirrored between the two. I will say that I don't like building mex files using mex command inside of the interpreter. Personally, I find it easier just to use a build system like CMake. Mex files are just dynamically linked libraries that link either to libmx and libmex on the MATLAB side or liboctinterp on the Octave side. They look for name mexFunction on our end. As such, I have a flag in the build file to switch between MATLAB and Octave headers and libraries depending on what platform that I want to build for. Just be sure to separate out the binaries because those aren't really compatible between the two and the licensing between them is different as well.
Citation: go on github, search PRML and look at the Python versus Matlab results.
I don't know why people have a problem porting Matlab code to Octave; it's been drag and drop for me except for the more esoteric package dependencies.
That said, I sometimes feel Octave is too much a clone of Matlab, warts and all, and I'd rather give up some compatibility for genuine improvement. (Same way I feel about LibreOffice or OpenOffice sometimes.)
exp(-i*pi*[0 0.5 1])
import cmath
import numpy as np
np.exp(-1j*cmath.pi*np.array([0, 0.5, 1]))
When you are experienced in Python, you know these differences by heart. But if you are a domain specialist and want to test an idea quickly, you will see lots of TypeError messages from Python, you need to google manuals to sort it out, and it will slow you down 10x.
1) there is no need to import anything but numpy to get at pi or e (see constant section of numpy docs).
2) if you wrap all your things you expect to behave like vectors/matrices with np.array() and only use np methods to operate on them you will suffer from shape mismatches instead of TypeErrors, a slightly better fate.