I’m curious, not saying either option is bad.
Once the pipeline is set, Python is for scripts that need to be run more than about a dozen times, or need to be run on several datasets, or for things that need to be reproduced exactly (like stuff that goes into a paper). I also use it to prepare datasets from large numbers of calculations where the useful results need to be gathered from dozens/hundreds of files in a more or less complex file structure, often on different computers, with the occasional pass with some post-processing tools.
I really dislike Matplotlib, so rendering is done in something else, usually gnuplot.
That’s for my stuff (mostly atomic-scale modelling and quantum chemistry in materials science), it might be different for other use cases...
That said I may use matplotlib much less than you do (I used it a lot when I was a student, now maybe 6 times a year).
This! My biggest gripe against Python numerical stuff was matplotlib, until I realized that it is an entirely optional component of the stack, and you can plot by other, much saner means.
If I'm using Matplotlib, I'm almost always plotting things calculated in Python, so all my data and variables are right there ready to go. I think the fine details are controllable in more programmatic ways than Gnuplot. I use other Python libraries when they're a better fit. Being Python and object oriented makes it easy to figure out how to do many things (e.g. autocomplete).
If I'm doing one-off throwaway plots, there are better and easier tools than Gnuplot: Desmos, GeoGebra.
If I'm making interactive demos, there are better tools than Gnuplot: Desmos, GeoGebra, JSXGraph, Jupyter.
If I'm plotting a function for a high-quality PDF document, TikZ gives me more control than Gnuplot, and makes it easy to make many plots with consistent (and changeable) style, though being a Latex-based tool it has limitations to go with its power. TikZ is great for diagrams too. Asymptote is more powerful than TikZ in some ways for this kind of thing, but often harder to use.
I was mainly commenting on its configurability. Gnuplot lets you (once you figure out how) control everything; for example, the exact shape of the arrowheads in a vector plot.
(The name is “gnuplot”; it’s not a GNU project.)
This of course works with other symbolic manipulation:
My use case is not a scratch pad with one plotting window; it’s dozens of windows with regressions and stuff. Each window is a completely different context; some of them are short lived and some of them are used for weeks. Using as many notebooks is very impractical. For example, seeing where one parameter is going in one calculations is trivial and quicker than starting a notebook and setting it up. Works transparently over ssh, too.
I am more or less fluent in Matplotlib, because I work with people who use it and I need to understand whatever the students are doing (and some of them use Python and some use R, which is a whole other discussion). I just dislike it and don’t use it much for my things. Ultimately, gnuplot’s syntax for regression and complex plots is much more concise.
I any case I think it’s good intellectual hygiene to use several tools regularly, lest you end up stuck in a way of thinking, so I encourage students to try others. It’s also good to have discussions about these things that don’t end up in holy wars; we need to be curious.
from sympy import *
x = symbols('x')
You just want to plot the sine function, but first you have to import libraries, declare symbols (with a scary correspondence between strings and variable names), and finally plot the damn function.
Edit: plus, if I'm plotting with Sympy it's almost certainly something I've calculated symbolically with Sympy, so everything is defined and ready, and it's much more elegant than switching to a separate program. For a one-off "what does function look like?" question, both these tools are far too clunky, and I'd use Desmos or GeoGebra.
Sympy is just a Python library, and one of the types it defines is symbolic maths variables, so you define Python variables just like with any other library, and then use them.
And this, my friends, is why mathematicians will never feel at home using Python+libraries. Instead of having a programming environment ideally suited to the needs of math, you need to fit your math to the Procrustean bed of Python syntax.
I'm glad I'm not alone. I was starting to feel crazy—how can something with this bad an API (Matplotlib) be this popular in the Python ecosystem which is known for its lack of verbosity and clarity? How can it be integrated with every other package instead of some sane alternative?
I tried Seaborn (a wrapper effectively), and it is way better for doing basic plots. But as soon as you get beyond that you're back in arcane Matplotlib territory. The best thing I could have done would have been to ignore its integrations and start with a better plotting API to begin with. The little bit of extra integration effort would have been worth avoiding Matplotlib. And there are several alternatives in the Python landscape.
No offense to the authors—it's clear they've done a lot of great work. But I think they got stuck with a bad API that they started with and it became so common-place that they were forced to continually be backwards compatible with something that really needed an overhaul.
I honestly moved on to gui based plotting programs like grace or veusz, there's just a button for the things you want to do
(I think matplotlib has an openGL backend that slightly improves but doesn't fix the issues with matplotlibs handling of large datasets)
In the beginning I had started with matlab because my lab mostly used matlab functions. Obviously it's not that I couldn't finish my work on matlab, but I found octave nicer to use, better publication-quality graphs, very friendly open-source community, submitted bugs typically fixed within a couple of days (which was not the case when I submitted bugs in matlab, of which I had reported plenty, particularly when it came to misbehaving graphics), interesting outlooks from studying its source code, ability to keep or distribute my code in the absence of a prohibitive matlab licence, etc.
It is probably true that it is not necessarily as quick as matlab or julia these days, however there is a big red flag when one looks at "benchmarks" online, which is typically that these are used in such contrived ways that a proper octave user would probably not consider as good octave code. (I remember this was also true of julia's benchmarks against python for instance).
Octave in fact is very powerful. Not to mention that to the serious user, much of its power comes from its incredibly powerful interface to its vast library of open-source c++-implemented functions.
As for the why octave and not python (or any other X) question ... honestly, I don't know. E.g. why Linux and not Windows? Honestly, both are fine. But, without having an explicit list of arguments, I just find linux is more enjoyable and gets out of my way, whereas on windows I find myself having to do extra steps and double-check things at every turn. Well, somehow, I have the same vibe when working on octave vs python or julia. But that's not to say I don't enjoy those other languages too. To me it just feels Octave is just ... nicer and gets out of your way somehow. It's definitely my language of choice for quickly trying ideas out.
MATLAB takes a while to start, Julia and Python need to spend a good amount of time importing/compiling.
My license doesn't allow multiple computers, so MATLAB is living on my laptop. I'd rather run longer computations on my desktop system, which can handle these loads for a long period time without getting stressed thermally.
My use case is to run ground-truth code designed by my professor and cross-check the results generated by my scientific software. These MATLAB/Octave generated values are also incorporated to sanity check and CI pipelines to test developed software's sanity and computational integrity.
The Achilles heel here is that in Matlab, there's quite often a licensed toolbox dependency which makes portability more challenging. Every now and again I've seen pure Matlab code and the Octave transition is smooth. Sometimes there are so many toolbox dependencies that it just isn't even worth trying.
However, we're living in a matrix world. MATLAB is slow and Octave is even slower while working with matrices. I have no idea how to fix that part.
I'm curious what you mean with this. Matlab was always fast with matrices (but my experience is now from 2 decades ago). The thing that was slow was loops. That is:
for i = 1:100
c(i) = a(i) + b(i);
c = a .+ b;
Better than python because I don't have to import libraries.
MATLAB had another significant advantage over Python. Its plotting support is really really really good. Given how much time scientists spend making graphs it's hard to understate how important that is, or how much better MATLAB is at plotting than Python or Octave (or Julia).
Having made hundreds/thousands of plots in each, I think Matplotlib's plotting is a bit better than Matlab's, especially for complex plots where you need control and have subfigures, etc. Matlab's 3D plots are better than Matplotlib's (which are fake-3D), but for sophisticated 3D visualisation Python has powerful options like VTK that Matlab can't really match.
To make sure I’m understanding you correctly, you’re saying Matlab is much better at plotting than Octave? I’ve only ever used the latter, so I guess that would be one reason to consider switching to the former.
What quality differences do you refer to?
Today, I am a heavy user of Octave's linear algebra algorithms for large sparse matrices. I also use Python/numpy for other things, and sometimes for linear algebra too (due to the insistence of my coworkers), but it is much less pleasurable and quite annoying. Also, the linear solvers in scipy are sub-par compared to the state of the art solvers in Octave. Once, we found a well-conditioned 6x6 system that linalg.solve failed to solve!
As an aside, I have never used Octave for plotting, and I hate the gui interface; my use case is 100% non-interactive, using scripts.
Now that both projects are mature, I think it's safe to say that matlab has 'borrowed' a lot of octave's nicer features over the years too (though obviously it's not something that can be publically admitted), like implicit broadcasting, command-line functions etc.
Obviously, neither matlab nor octave are strict subsets of each other. Also, I get the impression that matlab has started taking octave's compatibility very seriously in recent years, and has taken non-trivial steps to break it (annoying, but totally fair, in my view), which octave has resisted for the sake of backwards compatibility. Ironically this often makes octave a more reliable base for runnin older matlab scripts, than matlab itself. (e.g. in the same way that Wine is more reliable for running Win98 applications than Windows 10)
Nobody calls Linux a "clone" of Windows or vice versa, because even when they implement the same features, in the vast majority of cases the command syntax, APIs, etc, are radically different. There are a few commonalities, but when they exist, they are almost always because both have decided to implement some pre-existing standard. Even when Windows borrows features from Linux/Unix, it normally changes the API in incompatible ways – Windows 10 added pty support copied from Unix and Linux, but came up with an incompatible API to do it (CreatePseudoConsole)
It is the fact that Octave quite intentionally copied a lot of Matlab's syntax which leads it to being called a "clone". If they hadn't done that, nobody would apply that term.
> I think it's safe to say that matlab has 'borrowed' a lot of octave's nicer features over the years too (though obviously it's not something that can be publically admitted), like implicit broadcasting, command-line functions etc.
When Matlab "borrows" features from Octave, does it intentionally choose the same syntax, or does it implement the feature in an incompatible way? The former would constitute cloning, the later would not.
Once I inherited code written for octave. Did its job, worked like a charm, mostly. The CLI interface was clunky compared to typical shell tools so I had to do some shell wrappers and incantations to automate what I wanted. I don’t know if this is due to the author or to octave but I suspect its focus is on interactive use to the detriment of developing programs.
I keep a jupyterlab docker container running at all times on my win10 laptop, with windows-home mounted. Instantly available notebooks from my browser - works like a charm for interactive use.
I much prefer python since it lets you move continuously from one-off hack in a notebook cell to a web scale application, parses any weird file, serves web content in 3 lines, etc.
I can confirm this, but, Conway's Law suggest that this reflects more the user group that the language. Matlab provides all the typical suspects for structuring codebases (packages, classes, functions, globals, etc) but look what users do with it. This suggests simply that research groups " communication structure"s are huge messes.
Octave is slower than Matlab (at least last time, no loop acceleration), and no GUI library. So we went straight to python.
But don't you find python slower? I prefer octave to python, in part, because the linear solvers are much faster (and the startup time, too).
Are you using numpy? If so, can you give a concrete example?, in my case the opposite seems to be true. The numpy notation seems to be much clunkier.
Apart from that, this sentence:
> To get fast you need to vectorize.
describes a very sad tragedy of numerical computing. It makes no sense that in 2021 interpreters for scientific languages are not able to optimize loops. The so-called "vectorization" should be a non-issue in a modern interpreted language. The running time of calling "C=A*B" and that of the triple loop to fill the elements of the matrix C should be identical.
Also, symbolic calculation is a lot less cumbersome than in python!
Octave was really good to prototype and enabled me to get somethings done really quick. But once I got to know the python libraries better it just seemed easier. I could do all my data processing and quants in a single language.
I'm sure much has changed and was actually quite sad when the original author of Octave (John Eaton) mentioned in 2017 that he was unable to maintain it.
I've lost touch on Octave over the years and genuinely pleased to see that it is still being actively maintained. I think its time for me to see what I've missed in the past 13 years.
Details in my previous comment: https://news.ycombinator.com/item?id=25441585
However, its lack of support for Unicode variables and filenames is very frustrating in this day and age…
(I understand that they are being stuck due to Matlab having poor support too.)
I don't use Octave, but I have a little in the past, and I have to teach students to use Matlab (2021 should be the last year of that before we switch to Python though), and I've done a lot of numerical and other programming in Python and Matlab, in each for ~20 years.
In my opinion Matlab is a terribly designed language that has haphazardly grown features by accretion. Anything other than matrices and vectors is far more difficult than it needs to be. Therefore I consider Octave a bit of a lost cause; I think aiming for compatibility with terrible won't lead anywhere good.
Actually Octave has one useful feature Matlab is missing, operators +=, -=, etc., so perfect compatibility is not exactly the goal.
It seems to me the only reason to use Octave is if you happen to have a large legacy Matlab code base that doesn't depend on any of Matlab's proprietary toolboxes (unlikely, as those toolboxes are one of the main reasons people use Matlab).
I believe Python is superior to Matlab/Octave in almost every way. I think Matlab/Octave has two or three very small advantages over Python, and one larger but very niche one:
1) Matlab/Octave's matrix literal syntax is nicer and less verbose ([1 2; 3 4] vs. np.array([[1, 2], [3, 4]])). Irrelevant in most cases, as most substantive programs will have few literals in them. Note that those missing commas are a frequent source of bugs, too, e.g. [1 -2; 1 - 2] is an error, so really the Matlab/Octave is better written as [1, 2; 3, 4].
2) Because Matlab/Octave is primarily for numerical calculations, you don't need to import libraries to get started. Not a big deal as I always have a Jupyter QtConsole running with Python, Numpy and Sympy ready to use.
3) Basic 3D plotting in Matlab is still a little easier (Python is better for complex 3D plotting though). Not sure what Octave's story is for 3D plots.
4) The aforementioned proprietary Matlab toolboxes, if you happen to be working in one of the narrow niches they're good for. Python has similar large library advantages in other (and more) areas. Octave has some equivalent open source library bindings, but that's the biggest incompatibility with Matlab.
20 years ago Matlab was pretty good, but it's barely changed since then, and Python has long overtaken it in most areas. Octave seems to have caught up with Matlab on the GUI front (but Jupyter Notebooks are much nicer for many things (Octave can do Jupyter too), and Python has a selection of mostly equivalent IDEs, e.g. Spyder). Python, being a general purpose programming language, can do all the non-maths things surrounding the maths much easier. Data input/output, data processing, string processing, network access, etc., as well as UI things like Jupyter Notebooks. In my opinion Python's also better at quite a lot of maths stuff, like large integers, arbitrary precision, symbolic algebra, higher dimensional arrays, or dataframes with Pandas. I also much prefer 0-based indexing and half-open ranges.
Matlab's licensing is quite problematic. Licenses for business/research use are incredibly expensive, and licenses for student use are relatively cheap. I consider it unethical to teach students to use a proprietary language that will cost their future employers thousands, but that's been Matlab's sales strategy for decades. Switching to Octave is an option for teaching and some business/research use, but switching to Python, with its much bigger ecosystem, seems more sensible to me (unless you have a big existing Matlab code base).
If I'm allowed to offer a (non-opinionated) counterpoint, I have almost the opposite experience and opinions to you (both in the positives and negatives).
Background: I have been working daily with python for the last 3 years in a scientific field. Before this, I worked daily with octave for about 3 years in a similar field. I'm equally happy and skilled in both languages.
So, to counter:
point 1: I mostly agree, though I think the 'frequent source of bugs' point is slightly dramatic. If anything, to me it feels like the numpy system is much more conducive to bugs (e.g. given all the acrobatics one needs to do to ensure compatible ranks).
point 2: You absolutely do need to import libraries in octave. And that is generally a positive thing for a number of reasons, not too dissimilar to python. However unlike python, the octave team maintains relatively strict control and quality-processes for 'official' and 'endorsed (third party)' packages. This has an advantage over python where for each popular package there are 100 clones and variants and poor or unfinished packages, sometimes even phishing packages.
As for 'packages' in matlab, it's true you don't need to 'import' toolboxes, but this is only because of matlab's business model which sells them as add-ons. You can think of 'enable in licence' as an import of sorts if you'd like.
point 3: Octave derives its plotting syntax from matlab, and for the most part it's very intuitive. I always felt matplotlib is a poor attempt at replicating that syntax, but thankfully there are alternatives.
point 4: It's true that octave's biggest compatibility problem with matlab is in the 'toolboxes vs equivalent package' case. Which is partly why octave has been providing bindings to equivalent python packages as a workaround (same as Julia). One of the more successful examples is octave's reimplementation of python's sympy package, to create a symbolic package using matlab's api and simplicity of syntax, but calling python's sympy under the hood.
As for the "python has more stuff", this is purely the networking effect. And while obvioulsly the networking effect is not a trivial issue for any language, as an open source project it is always a matter of time, which is not something that can be said for something like matlab. And I'm sure that octave's rising popularity in recent years through its promotion in things like Andrew Ng's introductory course to machine learning, can only lead to an increased engagement with the language, and we can expect lots of good packages to crop up as a result.
point 5 (not labelled as such). I don't think the "python > matlab/octave" mantra is necessarily true. It's just personal opinion + engagement. It is certainly true that python has more users, but there are many reasons for that which cannot be reduced to a simple "python > matlab/octave". As for jupyter notebooks, I really dislike them and much prefer matlab/octave's 'publish' for producing straightforward html reports. But, again, that's just personal preference. Also, I much prefer 1-bassed indexing and closed ranges, as I find them much less prone to bugs.
I agree about the prohibitive nature of Matlab's licence, but I do not necessarily agree that the "natural" choice is therefore python. Surely the decision is more multifactorial than that. After all, if it's ecosystem you're after, why not julia? or c++? or java? In my view, octave is a reasonable contender regardless of an existing matlab codebase. It is a friendly language, with a big open-source community, excellent math and graphing facilities, and can easily interface with other languages if you really need that extra pizzaz on occasion, without the overhead that comes from needing to have your whole project based on those languages.
There was a point in my education where I had mastered my trusty TI-83; I knew the purpose of every single function and how to use them. But then, I started running into problems in the real world that required more than 32 KB of memory to solve. When I moved to a laptop I had to relearn all of that knowledge again. Haven't touched my TI-83 since.
It would be nice if the tools we learned how to use in school could also be useful in solving our problems after we graduate!
* There are a few aspects where it is better. For example I believe the variable editor introduced one or two releases ago is nicer as it allows inline evaluation.
I still think Octave has a niche to fill for students and HPC where software engineering (package management, compilation etc) is of insufficient concern.
At the college level, at least for engineering programs, at my school there was a pretty big emphasis on doing a lot by hand besides trivial stuff like addition and multiplication. The extent that we would utilize calculators seemed very minimal. Most of the degree programs including teaching students one or more of Mathematica, matlab, octave, and R. But I would say it sounds like the depth you had for the TI-83 doesn't really exist in the modern education, rather it is a more broad use of multiple platforms.