News for hackers. Stuff that matters.
Re:A new release for GNU Octave by mkl on Sunday January 03, 2021 @06:17AM (#25621125)
I'll say one option is bad :-)

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).

Re:A new release for GNU Octave by rcxdude on Sunday January 03, 2021 @07:02AM (#25621289)
I agree wholeheatedly. Python is everything matlab the language could hope to be and more, if you just want to crunch matrices python beats matlab as it's own game (just the broadcasting features in numpy alone are an amazing step up from matlab's approach, let alone trying to ingest data which isn't a csv). But, some of those toolboxes are pretty damn good and don't have an equivilent in python. For example, if you're doing almost anything with control theory then there's some pretty killer toolboxes that don't have any real competition, especially in the open-source space (there's some basic stuff but it's not particularly usable).
Re:A new release for GNU Octave by pvitz on Sunday January 03, 2021 @08:40AM (#25621696)
I have never understood why MATLAB hasn't introduced proper broadcasting like APL and its successors. My problem with Numpy is its awkward notation/syntax when compared to Matlab/APL.
Re:A new release for GNU Octave by tpoacher on Sunday January 03, 2021 @11:24AM (#25622684)
Matlab has had broadcasting since 2016 (and obviously octave since forever)
Re:A new release for GNU Octave by pvitz on Sunday January 03, 2021 @11:38AM (#25622791)
That is true, but "proper" broadcasting should include some way to manipulate it like a rank conjunction.
Re:A new release for GNU Octave by bori5 on Sunday January 03, 2021 @04:07PM (#25625250)
“ 20 years ago Matlab was pretty good, but it's barely changed since the “ How do you define “barely” looking at just changes from 2015 to 2020 in just core MATLAB shows at least the following changes.

https://www.mathworks.com/help/matlab/release-notes.html?cat...

Re:A new release for GNU Octave by tpoacher on Sunday January 03, 2021 @12:05PM (#25623023)
It's important to be aware this says more about you and your personal preferences (and possibly experience and skill in either language) than about octave and its overall value-proposition as a project though.

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.