Matlab and Octave are both easier to do some basic numeric work for people (frequently engineering and science students) with only rudimentary programming experience. In undergrad you write very little code, but do a lot of plotting and it is helpful that the Matlab IDE has all of that natively builtin. I prefer Python & Julia now, but getting something like Matplotlib working with Python would've been more difficult for me in college. Also, Matlab has native support for matrices and numeric operations (inversion, transpose, solve) that students need without having to learn how to use something like Numpy. My preference depends a lot on whether I'm doing exploratory work or trying to craft high quality software to run in production.
import cmath
import numpy as np
np.exp(-1j*cmath.pi*np.array([0, 0.5, 1]))
Note that you can't use math.exp for complex numbers, and neither math.exp nor cmath.exp works for arrays, you need the separate np.exp. Also, while np.exp actually works on lists, the multiplication doesn't, so you need to keep in mind which variables are python lists (that you mostly cannot do arithmetic on) and which are numpy arrays.
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.
I work as an applied mathematician writing numerical codes and I prefer to prototype in MATLAB/Octave for a number of reasons:
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.
That’s a well thought out argument and I appreciate it.
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.
For sure and I agree with many of the difficulties associated with MATLAB/Octave. When I want to put together a more complete piece of software that does things like: have a GUI, interact with a database, network conductivity, or parse files, I think that MATLAB/Octave is a poor choice.
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.
The other thing Octave/Matlab has over Python: it's a lot easier and clearer to express numeric algorithms in Matlab than Python, as Python isn't designed as an array language.
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.
I only had short experiences with MATLAB/Octave as a student but found that writing MATLAB/Octave rather than MATLAB or Octave was tricky... (IIRC mostly with differently named library functions)
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)
To me, it depends on how toolbox dependent your code is. Octave Forge has a lot of really nice libraries, but their interfaces tend to differ from MATLAB toolboxes, so getting codes to go back and forth can be a pain. In core MATLAB/Octave, most of the code is the same with some minor differences. For example, Octave doesn't care about wrapping a line with ..., but MATLAB does. Honestly, that's the most common issue that I have, but the MATLAB parser finds it and it doesn't normally take me more than a few minutes to fix things.
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.
As someone who is still annoyed that their degree program (a non-CS engineering) had them use Matlab instead of Python, I find it hard to disagree with those points. I will say that I definitely enjoy the 1 based array indexing.
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.
> Matlab is usually only ~$20 for an engineering student
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.
1.) I'm not sure why you appear to be taking an aggressive tone :)
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.
There was a little bit more information about that above. I'm a professional and my initial cost was around $2k and my yearly cost is around $400. I don't have to pay the yearly, but I like the updates and I like getting a response when something breaks and I'm on a tight deadline.
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.
That's a pretty good and useful point. I don't sell software (just use what I write), so I'm not worried about encrypted binaries at the moment. If I was actually selling software though I probably would be. The GPL has always been a double-edged sword to me. Sure it is nice and free as in beer and freedom, but it can also essentially mean that it is a complete no go.
The argument for a language like Octave/Matlab is analogous to why GUI software coexist with CLI alternatives. The Octave/Matlab audience may not be as technical and require a tool that has built in modules/libraries for advanced plots (without a lot of technical pain) etc.
I work in an academic setting. If I had the choice I'd prefer Python (or even Julia), but frequently Matlab is what's appropriate in a lower-division STEM (non-CS) course because it's what many engineers are used to and teach or expect their students to know. I'd rather use Octave than Matlab in such settings, and encourage students to do the same. Also, Matlab is still much more common (at least in undergrad engineering courses, not so sure about actual usage in the industry) than Python or other similar tools, and it's good to have a free software alternative.
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.)
For those who also use Matlab/Simulink for simulation, Modelica could be a nice alternative with an open implementation, which also has serious industrial application like controlling power plants.
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.