A new release for GNU Octave
lwn.net
lwn.net
Just yesterday I was trying to help find a bug in a hobby GPS software, where the map projection was off by a bit, resulting in surfaces that were off by 5% compared to Google Earth. Someone had written a little library for matlab and gave it away on the mathworks website.
Being able to test that library without matlab, confirm it was working, then using Octave to debug the translated code was invaluable.
After debugging and confirming both version gave the same result, we were closer to the Google Earth solution, but still off by a bit. That’s when we learned the projection used by GE isn’t very good to compute surfaces, and ours was actually doing a better job. Octave turned day+ job into a one hour session.
Massive thanks to the authors, and the author of that matlab library!
Since it seems researchers are migrating away from MATLAB itself to python (numpy/scipy).
BTW, GNU Octave is fantastic! You can setup termux ([1]) in your android phone and `apt install octave`. Now you have a portable REPL for many advanced mathematical problems you might face for example in solving homeworks (Singular Value Decomposition, Curve Fitting, etc)
Besides, the sparse linear solvers are much more performant in octave than in numpy.linalg (because the scipy developers are notorious anti-GPL fanatics and they refuse to use the state of the art free solvers due to stupid license reasons).
I for one use octave almost everyday, and I'm a bit annoyed when I have to turn something into python.
Also python being a general purpose system brings its own benefits, one can easily hook up ones code to fetch or push data to databases and even easily scrape data of the web or extract/reparse/rectify/reformat poorly/complexly structured data before processing.
And I find MATLAB not feature rich in terms of being able to manipulate tabular data in a relational DB like manner, that is querying/projecting/selecting rows/colums to find interesting facts.
Most programming languages are tools for making tools. Matlab is the tool itself.
I've seen scripts where you have to set up your matrices, manually put them in particular named variables, and run them through a script that was basically a bunch of matlab shell commands listed one after another. That's not scalable of course, but if elderly professors were willing to mess around with makefiles, dependencies, interfaces, and importing stuff then grad students would all find themselves unemployed.
I've done tiny prototypes that I later turned into a nice little Python+Numpy+Scipy scripts, and the final Python version was much nicer, but writing it was still more like a couple hour project, compared to the real-time process of figuring out what I wanted, done in Octave.
Check out SciML, Julia's answer to scipy (https://sciml.ai/) and Flux Julia's answer to PyTorch/Tensorflow (https://fluxml.ai/). Are these projects as mature as their Python counterparts? To be honest, no they're not, but they are making pretty rapid progress.
It's pretty much already decently configured out of the box, so you spend little time playing with build and project configuration and there's a debugger built-in. Syntax is straightforward and the language is pretty optimized so it doesn't take long to get a working simulation for an engineering major.
It breaks down horribly for larger projects however.
Yeah, the commercial plugins are also an interesting feature. The engineering focus of the platform makes it easier to do commercial development.
Octave has "toolboxes", they are called packages: https://octave.sourceforge.io/
I don't have extensive experience with Matlab's toolboxes, but my impression is that most toolboxes without graphical interface (e.g., optimization, signal processing) have an octave equivalent with the same function names and mostly compatible. What is missing are the "gui" toolkits like simulink, the circuit stuff, etc.
MATLAB is _approachable_ to engineers who don't give crap about programming, which often results in horrendous codebases (to be fair, I've observed the same, if not worse, with non-programmer's made Python)
> It seems to lack data structures that are quite pervasive in modern programming practise.
This however, is simply not true. MATLAB has many constructs to manipulate tabular and timeseries data in a very efficient way. It also has perfectly capable OOP, which allows building very large applications while staying sane.
MATLAB has evolved tremendously in the last 15 years, and most critics I read, while valid if you compared a circa 2005 version to current Python + numpy + pandas + scipy, are usually just uninformed.
At least it has multi-dimensional arrays of floats, that is all I need and are sorely lacking in Python. On the other hand, Python has dictionaries and strings, but those are completely useless in a numerical setting.
I agree that the M language is not a good general-purpose programming language. But for expressing linear algebra manipulations is probably the best in town.
I haven't had a lot of time to look into it but my hunch is it would be magnificent to code numerical routines in Julia and access them from Python. There was some work for adding that sort of an interface with octave but it never seemed to work well.
That said, Matlab does encourage quite a few bad habits that can kill performance in Julia, so it's important to try and properly learn Julia idioms too before you just blindly start translating if you care about performance.
My assumption was that Julia could at least match that as worst-case but offered better optimizations to get even more performance.
I guess it depends on what's considered bad habits. Octave/Matlab do tend to be not terribly memory efficient so I tend to just buy RAM and larger cache CPUs. But my domain is memory-limited anyway.
Matlab's JIT does enable some things that are dog slow in octave for example. I assumed that sort of thing would actually be faster in Julia.
Generally, naive Julia code shouldn’t be any slower than Matlab or Python, but it can happen. The Julia Discourse forum has many posts from people surprised to find their code running slower in Julia, but the community is also incredibly helpful so these posts almost always result in some rather simple modifications to the code that makes it handily outperform Matlab or Python implementations.
Best ODE/SDE etc support of any programming language. Including composing them with machine learning and AD, GPU, multithreading, DSLs and symbolic simplification etc
I too am trying pandas daily after matlab (and q/kdb) and getting more annoyed by the day, of how inept it is. :-O Then again, it could be me - a craftsman & its tools, etc.
If you use the numpy.matrix type instead of numpy.array, the * operator becomes matrix multiplicaton.
https://numpy.org/doc/stable/reference/generated/numpy.matri...
Anyhow, the * operator does not work with sparse matrices, and you really don't want to maintain two versions of your formulas. Thus, you are unfortunately stuck with @ or .dot
I guess there might be a much more math-friendly library than numpy, but I have never found it.
Huh, you're right. Bummer, I hadn't noticed that yet. I agree that an ergonomic matrix class is sorely missing in the Python ecosystem. It shouldn't even be that hard to implement, since all the plumbing is already there.
Now I don't know of a single peer that uses Ocatave, and only 2 that use Matlab. There are simply better alternatives out there.
Matlab and Octave are too "standalone" and too "slow" to implement into any real-time trading model.
I saw two big use cases for them 10 years ago,
1: writing Neural networks from scratch where you culd apply vectorized operations over multiple data at the same time.
2: Engineering work as Matlab had a huge, and just as importantly, well tested set of fortran functions for almost any engineering discipline.
Both of those uses cases were supplanted by other tools. The former by tensorflow, pytorch, pandas and numpy.
The later by excel in alot of instances but also the python eco system of numpy and bespoke libraries on top
The fundamental problem is MATLAB/Octave simply aren’t as useful as Python for real world stuff (a bit of syntactical awkwardness around linear algebra is worth painless web access and system IO). The languages also aren’t as nice as R for statistics and machine learning. And nowadays they don’t have much performance benefit either. In most cases I think Octave/MATLAB provide too little benefit and too many drawbacks.
Octave is a great option as a personal calculator, and be the best option for small mechanical/electrical engineering firms. MATLAB code is unusually clear and expressive for numerical calculus and linear algebra, so are a good choice for problem domains where the math is very complicated but the dataset isn’t terribly large (e.g., models of crack formation in ceramics). I worked at a place that used Octave to run a free MATLAB script that did some very complicated microeconomics: a lot of very smart professors have written many useful algorithms in MATLAB, so being able to run them without porting is nice.
But I think Python and R have, sadly, made MATLAB as a language mostly obsolete for future development. The real relevance is MATLAB as an analysis tool with lots of MathWorks goodies.
I think the universities use it for two reasons. Firstly, they’ve paid for the license and many proprietary add-ons, so they may as well use it. Secondly, MATLAB is a fast and safe playground for bright students who don’t know how to code. Teaching students to code well is too expensive (mainly in time).
While I was working on my masters (comp chem) I encountered a bottleneck written by a previous masters student. This was a python library. The student had written all his numerical methods manually. He was using python lists for vectors. His algorithms were great though. If you just use MATLAB, no one is making that mistake.
Personally, I find Octave easier to work with than MATLAB when developing applications because (1) It avoids the often times broken license manager and starts faster and (2) Has a more reasonable, integrated connection to the machine C compiler for debugging mex files. Especially for reason (1), my clients also prefer to use Octave when possible. That said, we often need to do production runs in MATLAB because they tend to use more updated numerical libraries than Octave. For example, Octave still has not migrated to SPQR from CSparse.
All that said, Octave has provided us with an amazing, reliable tool. It is not well suited for everything. It is incredibly well suited for implementing and rapid prototyping many kinds of numerical algorithms that take advantage of the ease of access to linear algebra operations.
- 3 teachers using Octave (and one of them wants strict Matlab syntax).
- 0.5 teachers using "C+" (C with some C++ libraries thrown in, but no OOP), with maybe some Python sprinkled on.
- 1.5 teachers using Fortran, with maybe some Python sprinkled on.
- 1 teacher using full Python (with numpy and matplotlib)
As far as I could tell, my undergraduate department ran on MATLAB (and I suspect it still does).
Python is also just ok. You can use matplotlib[1] to create plots using an interface explicitly modeled on the Matlab interface, or use higher-level wrappers like Seaborn[2] which reduce the amount of work required to create nice-looking plots of certain types. "Zoom to different features" can be done via Pandas[3], or directly via NumPy, although the syntax can get a little cumbersome. The best Matlab-like GUI is probably "Scientific mode" in PyCharm[4], which requires a paid license. Jupyter notebooks[5] are a free option, but don't include all the features you'd have in a Matlab-style GUI.
R is, in my opinion, best-in-class for exploratory data analysis. The combination of ggplot2[6] and dplyr[7] makes plotting, drill-down, aggregation, etc. easier than any other environment I've used. Chapters 2 and 4 of the free "R for Data Science" book[8] provide great examples of this. The RStudio[9] GUI is comparable to Matlab in features and overall polish, and it's available with either an AGPLv3 or commercial license. Jupyter notebooks also work.
The major downside of R is that it's very optimized for interactive use, which makes deploying it to any sort of production environment tricky and error-prone. I'd mostly advise doing your ad hoc analysis in R, but rewriting things in another language if you want to deploy them. The other downside is that all the major deep learning libraries use Python, so if you want to do work in that space you should really just use Python.
[2] https://seaborn.pydata.org/
[3] https://pandas.pydata.org/docs/user_guide/indexing.html
[4] https://www.jetbrains.com/help/pycharm/matplotlib-support.ht...
[5] https://jupyter-notebook.readthedocs.io/en/stable/notebook.h...
[6] https://ggplot2.tidyverse.org/
All that aside, I've noticed that when we bring in a new recruit, if they can code in MATLAB, they can switch to Python in a jiffy. I think the take-away is, if someone offers you a chance to learn how to code in any language, you should take them up on it.
Termux is such a lovely project. Works also great on chromebooks and chromebook tablets.
... and from python (numpy/scipy) to Julia
See also the thread from 16 days ago discussing the 6.1 release, at https://news.ycombinator.com/item?id=25252543
The main issue seems to be Matlab compatibility, which is stuck with UTF-16 (like some Windows internals), while most languages have moved on to UTF-8 as a standard (Heck, even Windows PowerShell (and Notepad?) default to UTF-8 now!)
Especially for the first one. Being able to use greek letters as variable names would be incredible (now that it is possible to do so in Python and in C).
I've seen people do that in Haskell, I think. I've no idea why that's desirable. It's difficult to type up. It only adds complexity. Is it to be able to use variable names like they're used in mathematics? That's optimized for easy handwriting, through terseness, but because of just how terse it is it's incompatible with autocomplete, so it actually offers a much worse writability/readability ratio in an editor. Why use a miniature vocabulary of symbols when you can use English? I'd always choose `delta` over `Δ`. Actually, why use greek at all?
I realise my insight is a bit condescending. My background is plain programming. I've had to implement some algorithms from papers. I guess I'm venting having to interpret those symbols, where terseness was favored over readability.
Yes. That's the main point (in my case). I'm really tired of having variables with ugly names like "alpha" and "beta", when I could have simply α and β, just like they appear in print.
> Why use a miniature vocabulary of symbols when you can use English?
Because that's the vocabulary which is already used in math, and I do not wont to change mathematics to adapt to the limitations of programming languages.
See, I don't coincide at all with your point of view, but allowing greek leters in variable names would not keep you from using your preferred naming conventions.
EDIT: it's not really "difficult to type" either. For example, in linux if you add
setxkbmap -option caps:ctrl_modifier
That's like saying that |||| is more readable than 4. Yes, it does take some time to learn the symbols. (I'm not sure what you mean about being incompatible with autocomplete?)
> Why use a miniature vocabulary of symbols when you can use English?
Why do you assume that English is going to be easier? Heck, even for a native English speaker not familiar with programming, √() is going to be easier to understand than sqrt() !
What would you say if you had to work on a code of Russian origin, would you prefer α or альфа ?
> It's difficult to type up.
Depends on your keyboard layout...
(Greek letters are accessible from AltGr+G.)
And I guess that they have to follow the lead of Matlab anyway, at the risk of going into another direction... EDIT : Yeah : https://savannah.gnu.org/bugs/?57103#comment7
Speaking of which, I should check how Scilab deals with it!
So UTF-16 is not the problem.
It's a bit complex, mainly due to hysterical raisins ^W^W historical reasons.
----
https://docs.microsoft.com/en-us/powershell/scripting/dev-cr...
> In PowerShell 6+, the default encoding is UTF-8 without BOM on all platforms.
I got used to reading UTF-16 text rendered as ASCII when dealing with NT :)
It doesn't :
On Linux :
- Can't use Unicode filenames
- Can't use Unicode identifiers
(- Actually, you can use Unicode in comments, not sure why I wrote that...)
It's true you cannot use non-ASCII UTF-8 names for script and functions, since in that case the file name is also the command/function name. But that's a statement about valid identifiers, not supported filenames. Every language I know of has restrictions on identifiers.
Fun memories, I implemented every basic algorithm of image processing in it.
Later I ported the algorithms to JavaScript and created a image editor:
https://github.com/victorqribeiro/photoEditor
Thanks to the awesome people from Octave.