Octave is a great tool, and it addresses a very real need - breaking MATLAB's stranglehold on academic computing.
Every programming course I took as an EE undergrad (other than Intro to Programming) was in MATLAB. 14 years later, and it's still the standard tool in my alma mater's EE department. Having a FOSS equivalent is huge.
So raise a glass to the Octave dev team. They work hard to provide a FOSS tool that can run MATLAB code, which gives you the software you need for self-guided learning from university materials. Or for your all your computational needs.
And Octave is a great tool even if you don't need MATLAB compatibility. Try it out the next time you've got some numerical computing to do.
Agreed that:
A) it and Scilab are great projects
B) these would suffice fine for pretty much any undergraduate course in linear algebra, but many courses need Simulink and I'm not sure Scilab's Xcos is good enough. Since Matlab is like $20 for students, it is basically free and makes sense especially when you consider the IDE. Sure, Python and Julia are great options once you can code. There are many students who honestly just aren't very good coders by their sophomore and junior years. Engineering students have to code here and there in various projects, but often don't have a full class just for programming. Long story short, inverting a matrix in Matlab/Octave/Scilab is more straightforward than in Python. I think Julia's syntax has enough similarities with Matlab and is similar, but the tooling would be confusing to students.
> 14 years later, and it's still the standard tool in my alma mater's EE department.
Unfortunately it's still omnipresent. Even in very basic courses, where the abilities of Octave would be enough by a large margin. I don't think it changes until the next generation comes.
I had a few younger EE professors try to get us to use Python for our coursework just to get pushback from the status quo students talking about "but what about preparing us for industry??". It was pretty disappointing since Python's so much nicer than Matlab for signal processing IMO.
What? The industry doesn't use matlab except a few big places. Of those, most are also now considering switching to Python. They need to get out there and do some polling.
My undergrad university was really involved with "heavy industry"-type companies for co-ops and recruiting, like utilities, chemical processing/manufacturing, and military-industrial for the 4.0 GPA kids. All the fields who offer you a gray cubicle to waste your life in while they kill the environment, and they're pretty resistant to changing anything. It was really unhealthy for getting a well-rounded engineering education.
I've been doing some hobby signal processing in Ruby just for the challenge and checking the results with Octave. Ruby is such a nice language, it's a shame it doesn't have anything like Python's scientific libraries.
GNU/Octave has a great strength and weakness that it uses the Matlab language. This is great for many who are educated with Matlab but don't know much else. After some time I found Python and the ecosystem around numpy/scipy/matplotlib fit my problems much better. Python just much more flexible and better suited for general programming tasks than that weird matrix oriented language.
Why should anyone use Octave over Matlab?
- Licensing cost.
- Freedom.
Why should anyone learn Octave instead of Python?
- It's a bit easier to get started for scientists who are not programmers.
- If you mostly do vector/matrix math, the language is nice.
- Otherwise I don't know any good point.
All in all I like a free alternative to Matlab but have the feeling that most people are just better served by joining the much bigger Python ecosystem. (Or maybe R/Julia/Rust which I don't know so much about in this context.)
I used Octave in Uni when my assignments had to be done in (commercial) MATLAB. I could get most of the code working at home, and then port. Matlab compatibility was the key benefit, even though the MATLAB language is a bit stupid.
And that was before numerical python existed. Now, MATLAB compatibility is about the only reason to use Octave. But a better idea is to get out of the MATLABiverse altogether.
As for reasons to use Matlab:
Matlab comes with XYZ toolkit: This isactually a good reason if you know that XYZ toolkit is your core business. In general though, the Python ecosystem is far bigger that Matlab's one.
Easy for scientist: Trap. Every MATLAB using scientist I know ends up with a code base that is too complex (~1000-5000 lines of code) for the language, but is perfect for Python. (Exactly like how programmers start projects with Python that then grow too big for that language).
Admittedly falling into the trap once might be cheaper than learning Python, assuming you never need to program anything again in your life.
Vector/matrix math: Numpy has all the same vector/matrix stuff including a class which does matrix-multiply under that '* ' operator like MATLAB. But that tMatlabhat operator is a trap: '.* ' is far more common in MATLAB code and accidentally using '* ' is a common bug. This is effortlessly avoided in Numpy standard classes.
> Every MATLAB using scientist I know ends up with a code base that is too complex (~1000-5000 lines of code) for the language, but is perfect for Python.
My experience with this is that it is not the necessarily the language that makes it too complex, but the lack of training in proper software development. I have got mainly colleagues who were trained as economists, actuaries or mathematicians using Python, R, Matlab or Excel/VBA as the language of their choice and the result is always the same.
Coming from physics myself,I understand that beautiful notation can make things much easier and can be often the way to find great solutions, but proper organization will most often be sufficient.
Base R has some pretty big problems compared to Python or VBA. I'll single out the increasingly desperate attempts made to implement a map function in the *apply() function family; one of a number of key functions that from a user perspective return data in a random data structure. It is unreasonably difficult to maintain control over what the type of your object is.
Say m[1:2,] where "m" is a matrix. That returns a matrix. m[1,] returns something that is not a matrix. That sort of type soup breaks all sorts of things in an unhelpful manner. typeof(m[var,]) and class(m[var,]) don't reveal any information on the subject either. You need to explicitly test if you still have a matrix with is.matrix after accessing a sub-matrix of a matrix in the obvious fashion. That is an important operation. Good luck figuring that out if you don't already know what is going on; the design is awful.
The short story is to go install tidyverse and use that instead.
Yes, there are problems of this nature in R, but I don't think the specific case you cite is really a problem. The ultimate source of the difficulty is the R (really S) decision to not have scalars - only vectors that happen to have length one. But given that, writing m[1,] is normally intended to get a simple vector, not a matrix.
The problem really arises when you write m[1:n,] with the intent of getting a matrix with n rows, and n happens to be 1 at the moment, so you get a simple vector instead.
This is a problem that I have addressed in my pqR version of R, available at pqR-project.org.
In pqR, there is a new sequence operator, .., which produces a 1D array, not a simple vector. And in pqR, when a 1D array is used as an index, the dimension is not dropped, even if the array happens to be of length 1. So m[1..n,] produces a matrix even if n is one.
Well, most of the time. There's also the problem that m might have only one column, so the result will get dropped down to a simple vector for that reason. To solve this, pqR has a new way of indicating a missing argument, with _, which also indicates that you don't want the dimension dropped. So you can now get exactly the behaviour desired by writing m[1..n,_].
This is all backwards compatible, except that it's necessary to disallow use of .. in the middle of an identifier, so that a..b won't be taken as the name of a variable.
Ah, I've been intrigued by pqR. Lately I've wondered if there couldn't be a version of dplyr implemented as transducers, if only R... wasn't R. How feasible might it be for some future R runtime to be truly multithreaded, even if it breaks some existing functionality?
Well, pqR already uses multiple threads automatically to parallelize some numerical operations - e.g., for long vectors a and b, (a * b + a / b) might be computed with three threads, one computing a*b, one computing a/b, and one adding the results of these as they become available, or exp(a) might be computed with two threads each handling part of a.
But if you mean threads programmed explicitly in R, with fine-grained, low-overhead communication using shared memory, I think it would be quite challenging to modify the current implementation to support a language extension to do this. But maybe not impossible, for some sorts of extensions.
I think this point has great merit. From time to time I sit on the industrial relations board of our local university's CS department and I begged to have at least one basic software engineering best practice module as part of their new data science degree, with no luck. Many universities have Research Software Engineering departments now who can help with this stuff, but on the whole code produced by non-CS academics is dross (but honestly god bless you if you're offended by this characterisation and it doesn't apply to you).
> My experience with this is that it is not the necessarily the language that makes it too complex
It's not that the language makes the project complex. It's that the projects are by a bit more complex than the language is cut out for.
> but the lack of training in proper software development...
Assuming training scientists etc. in proper software development is a good use of their time (it might be); then MATLAB is a blocker because it makes it hard/ugly to implement "proper" techniques.
Again Python fits the bill here, because its a pretty good language for novices to hack around naively in, while scaling smoothly to projects 5-10 times more complex. So that the naïf has some headroom.
I used Clojure to manipulate the data, construct the system, think of R as a library of data analysis and data visualization, use DSL to call R, take the professional advantages of R, avoid the shortcomings of R.
Let professional language do professional things, and the advantages of various languages complement each other.
Dunno if you're aware of Bayadera[1], but if you happen to like a Bayesian workflow and don't rely overmuch on ggplot2 niceness, you can actually go a whole day without touching R.
R is actually a lot more concise than Python for a number of operations. Python wins when you consider the total ecosystem, but doing a broad comparison like that is unfair. it depends completely on what you are trying to achieve.
R has better data manipulation, algorithm support (outside of neural networks) and visualisation. Speaking as someone who has to maintain environments for a team of data scientists, getting R and RStudio Server installed with Intel MKL support etc is trivially easy. Getting JupyterHub, Python, Anaconda and your own compile of TensorFlow all up and running is _excruciating_ so I don't really buy that one ecosystem is provably better than another even if I think R is a horrible language in comparison).
The best I can explain it is that R is to data science as PHP is to web sites. It's an incredibly productive and accessible DSL, but you rarely want to inherit an R codebase.
> And that was before numerical python existed. Now, MATLAB compatibility is about the only reason to use Octave. But a better idea is to get out of the MATLABiverse altogether.
Personally, I do a lot of numerical calculus and prefer octave than numpy, just because the language is less verbose and more comfortable to use. I have converted many times ugly python+numpy code into beautiful octave. If your main and only goal is to perform matrix computations, then octave is excellent. I have never used nor needed the commercial matlab.
The python numerical stack has a rather absurd feeling in my eyes.
In an engineering setting, MatLab has more mindshare, but that may be changing.
The related product Simulink is not uncommon in larger engineering firms also.
Back in the day, the community around MatLab was quite large, but likely has declined in size in the last few years with the rise of Python in this area.
"Not uncommon" is an understatement. In some workplaces, Simulink is as pervasive and core to engineering as Excel is to the business world in general.
> In an engineering setting, MatLab has more mindshare, but that may be changing.
This has definitely been changing for a while. All engineering studies of my old university except for computer science and mathematics have switched from Java+Matlab to Python over the last years. I've already seen this have an effect on workplaces, where new students prefer to use Python and are generally allowed to.
> All engineering studies of my old university except for computer science and mathematics have switched from Java+Matlab to Python over the last years
I'd love to witness this. I used Matlab heavily as an engineering student, and now mostly work in Python. Python is definitely better for complex programming, but where the program is simple and the math is hard, Matlab seems like a great tool.
I'm curious what tools/libraries python users now use that brings Python up to the usability of matlab?
> I'm sure the massive savings on license costs also make it attractive.
I remember shelling out $60 for a true license of Matlab while in college. I remember thinking, "well you're an engineer now, and this cost is part of that", even thugh it felt like a small fortune. But official licensed version required you to insert the CD into the computer every time you used it, so I gave up a got the pirated version instead.
If you get the commercial version out of college it is thousands of dollars for base and thousands for each "toolbox". Want to have database functionality? Thousands of dollars, optimization functions? Thousands of dollars.
That might be worth it for national labs that like how the native IDE, plotting, GUI, widgets, ability to put into commercial projects (they've secured licensing for the math solvers for you)...etc. It is all better integrated than Python even with it's nice Spyder IDE.
I find that I'm more productive prototyping algorithms in Matlab than in Python. In fact, I tend to write it first in Matlab, port it to Python, and finally port it to C (to run on an embedded device)!
As for Octave, I've used it a couple times in the past but found the environment underwhelming (especially so when creating plots). I also tend to run into various compatibility problems when running scripts developed in Matlab.
I've used Octave and the Python stack and I can confirm that it is much easier to focus on the problem at hand using Octave. One can focus on the math and algorithms and not the language.
It is the same for me with R vs. the Python equivalents.
So your strategy of designing in Matlab and porting later (if necessary) makes a lot of sense.
I haven't used MicroPython and suspect it wouldn't suit my use case. I often have to design things that run on battery power (sometimes a CR2025) and so the firmware needs to be quite lean. Also most of the time is typically spent interfacing to hardware and peripherals so using something other than C wouldn't make sense.
Matlab is much nicer to use than python for problems that fall well into its (much narrower) niche. It's super easy to bash some matrices together with nice syntax, plot the results and interactively and iteratively develop code. Profiling python kinda sucks, whereas in matlab the IDE will color code each line of code based on profile information. Reloading python code sucks, whereas in matlab you just change a function file and the modified definition becomes immediately available in your interactive session. Everything is much simpler and more immediate (and of course also more limiting, if you want to do some general purpose software engineering). It also used to be significantly more performant than python for many important tasks (and maybe still is).
Octave, on the other hand is IMO really only of interest if you somehow need some degree of compatibility with the Matlab ecosystem or want to teach non-programmers how to do some basic numerical linear algebra stuff. Otherwise, if you want something free, just stick with python.
Matlab has lots of solvers for all types of families of differential equations. I think these are lacking (in their completeness and richness of documentation) in other programming languages ( at least this holds for R - much fewer solvers). I don't know how complete the Octave equivalents are.
The optimization functionality for linear programming, mixed integer linear programming...etc is pretty much non-existent in Octave. At least the kind of optimization common in Operations Research and used in production in thousands of companies world-wide. Python and Julia have libraries to call out to dedicated solvers like CPLEX, GUROBI, GLPK, and CBC/CLP that are written in C/C++. I'm not sure if Octave has a decent interface.
One thing I find handy is to format my debug printing for my vector and matrix types in Octave syntax. It makes it easier to debug my C++ code when I can copy/paste values directly into Octave for further analysis. e.g.
vec3f x = {1,2,3};
fmt::print("x = {}\n", x);
// output:
// x = [1; 2; 3]
I use Python for most of my general programming needs, but in an engineering environment MATLAB (unfortunately) still has an edge. As a programming language it’s quite sh*tty, but it’s strength is in the high quality toolboxes. I work quite a lot with constraint non-linear optimisation and I still have to find a Python or Julia library as flexible and robust as the MATLAB toolbox. I think Octave is a good FOSS compatibly solution, but the main strength of MATLAB (the set of toolboxes) is unfortunately missing.
MATLAB can charge for the software but making it opensource would be really ethical considering the software is used heavily in research. More eyeballs to view the correctness of the software is crucial.
Mathematica does so much more than Octave that it's not even remotely comparable. In terms of features, Octave inherited Matlab's matrix-centric mindset by having the \ operator solve linear systems whereas in Mathematica it's slightly longer (LinearSolve[m,b] or just Inverse[m].b for non-numeric ones). But Mathematica offers symbolic computing as well, and you can very easily go from "solving this equation with machine-precision numbers" to "solve this equation with arbitrary precision algebraic numbers" to "solving this equation with an unknown parameter with conditions" in a seamless way. There are whole areas of mathematics, pure and applied, that can be done in Mathematica but not in Octave. In terms of ease of use, Mathematica also excels here; both data and code share a uniform notation that is very similar to lisp, and functional programming ideas carry over very seamlessly.
I'd say if you are someone who's even remotely mathematically minded, learning to use Mathematica is an extremely useful experience. As an example that recently happened to me, while doing front end work I needed to construct certain geometric figures as an SVG polygon; I used Mathematica's built in graphics primitives combined with its plotting capabilities to find the polygon in no time. Even though the end result is a piece of JavaScript, Mathematica gives me a way to prototype the whole thing in an environment that's "batteries included" and well-polished.
>Mathematica is way more targeted to the "general public" though.
Actually, it's way more targeted to mathematicians. The level of symbolic computation it can do is way ahead of any symbolic toolbox you'll find. When I was in grad school, I used NumPy and my group mate used Mathematica. One day I was looking up identities in Gradshteyn and Ryzhik (a bible for identities), and he asked why I bother as Mathematica had it all. He challenged me to find any identity that Mathematica couldn't handle. I thought this would be easy as G&R has more stuff than any other identity handbook out there, but I lost the challenge.
Mathematica is useful and beautiful. But solving a linear system by the antislash operator is a major feature of octave and a piece of notation that I cannot live without.
Octave and Matlab focus on numerical computing, while Mathematica focusses on symbolic computing. The first means working with arrays (and higher dimensional arrays) of (mostly) floating point numbers, while the later means working with abstract syntax trees of mathematical expressions.
Specifically, the one "equivalent" to Mathematica is Maxima [0], I remember using it for symbolic computation on my linux machine. Especialy coupled with Wx GUI [1].
Both Maxima and GNU Octave are pretty old (mature?) projects with probably outdated-looking (feeling) GUIs. Just to mention some younger and more "fresh" projects: In the SciPy ecosystem, there is SymPy https://www.sympy.org which has the obvious advantage of being Python, gaining from a big (also scientific) ecosystem, such as numpy, pandas or the JupyterLab.
A large OSS player is nowadays also SageMath https://www.sagemath.org/ which is a kind-of-meta CAS which can actually proxy evaluations to Mathematica, Maxima, Octave and many others, in a more or less uniform pythonic notation.
Probably needless to say, when it comes to evaluation power (for instance for integral solving), Mathematica is unrivalled from OSS projects. However, in certain fields (such as number theory for SageMath or the overall web notebook infrastructure by the IPython and Jupyter projects), the concurrency is catching up or may already have overtaken Wolfram's products.
Wow, sympy looks amazing. Seems to solve exactly the kind of things I'd use Mathematica/Wolfram for, especially back in my university days. Will play around with it when I have some time to repeat my math knowledge, been meaning to refresh some things for a while now.
I've not used Mathematica, so my views would be as useless here.
Octave can be greatly compared to MATLAB. It actually tries its best to be as compatible with MATLAB as possible.
So, one can say it is as closed to Mathematica as MATLAB is.
part of one of my previous jobs involved converting code from MatLab to Scala. Needless to say, it wasn't very fun.
Languages like Matlab, Stata, SAS, or R don't seem to be designed for professional developers. They tend to break all the assumptions that every other languages have (like array indices beginning with 0). I also feel this way about Pandas, it seems like it was designed by a data scientist and not a developer.
Because the people using these particular languages don't care about elegance (they usually just want the graphs or papers or whatever) and that no one is writing commercial systems that need to be maintained, there's no real incentive for them to design a language that makes any sense.
Making things ad-hoc and less axiomatic does have its benefits however, these kinds of languages can be surprisingly expressive and powerful.
Octave is a great tool, and it addresses a very real need - breaking MATLAB's stranglehold on academic computing.
Every programming course I took as an EE undergrad (other than Intro to Programming) was in MATLAB. 14 years later, and it's still the standard tool in my alma mater's EE department. Having a FOSS equivalent is huge.
So raise a glass to the Octave dev team. They work hard to provide a FOSS tool that can run MATLAB code, which gives you the software you need for self-guided learning from university materials. Or for your all your computational needs.
And Octave is a great tool even if you don't need MATLAB compatibility. Try it out the next time you've got some numerical computing to do.
Not an Octave dev, just a fan of the project.