News for hackers. Stuff that matters.
Re:A new release for GNU Octave by ducktective on Wednesday December 16, 2020 @06:18AM (#25441312)
Is GNU Octave still relevant in the fields where it once was considered as a FOSS alternative to MATLAB?

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)

[1] https://wiki.octave.org/Octave_for_Android

Re:A new release for GNU Octave by enriquto on Wednesday December 16, 2020 @08:14AM (#25442089)
GNU Octave is a much better language for linear algebra problems that python+numpy. If all you have to do is state and solve some systems, you can typically do it in one or two lines of octave, while in python you need to import libraries and use a bizarre notation (either @ or .dot look very ugly in formulas).

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.

Re:A new release for GNU Octave by billfruit on Wednesday December 16, 2020 @10:43AM (#25443888)
MATLAB seems ill condusive for structuring and organising code in a sane manner. It tends to give its users bad habits with respect to structuring code is what I observe. It seems to lack data structures that are quite pervasive in modern programming practise.

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.

Re:A new release for GNU Octave by bee_rider on Wednesday December 16, 2020 @12:00PM (#25444902)
This makes sense, though, because it isn't really a general purpose language for creating standalone programs. I mean, you can try that, but it is a bit awkward. The usecase is mostly "I've got some matrices and I want to try some things with them before writing a couple thousand lines of FORTRAN with a bunch of ugly BLAS calls."

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.

Re:A new release for GNU Octave by billfruit on Wednesday December 16, 2020 @12:13PM (#25445118)
That Ok, but when more elegant and refined tools are available shouldn't they be preferably selected to be used.
Re:A new release for GNU Octave by bee_rider on Wednesday December 16, 2020 @12:21PM (#25445257)
Yes, if that tool were created, I bet it would be really popular. But it hasn't been. Python+Numpy+Scipy isn't it by virtue of the fact that we have to specify three different software packages, haha.

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.

Re:A new release for GNU Octave by valarauko on Wednesday December 16, 2020 @12:58PM (#25445833)
How does Julia compare to Python+Numpy+scipy and Octave?
Re:A new release for GNU Octave by UncleOxidant on Wednesday December 16, 2020 @02:02PM (#25446867)
It compares quite favorably. The nice thing is that most of Numpy and Octave functionality is already builtin to Julia (multidimensional matrices are first class as they are in Matlab/Octave). Julia performance is quite good and multiple dispatch is great for composing packages (once you get used to it).

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.

Re:A new release for GNU Octave by bee_rider on Wednesday December 16, 2020 @01:03PM (#25445906)
I haven't tried it out. It seems really interesting, though. A guy in my group loved it, but he graduated. I haven't yet so I guess we can put at least one point on the board for Julia!
Re:A new release for GNU Octave by enriquto on Wednesday December 16, 2020 @12:18PM (#25445192)
Sure, and in that specific case octave is the elegant and refined choice!
Re:A new release for GNU Octave by 908B64B197 on Wednesday December 16, 2020 @01:00PM (#25445868)
The argument for MATLAB is the IDE.

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.

Re:A new release for GNU Octave by ljosifov on Wednesday December 16, 2020 @01:23PM (#25446195)
Agreed it is mostly used interactively in the IDE. FWIW one can compile into p-code (=underlying virtual machine), package the p-code files of the application with the matlab standalone engine+libraries (MCR), and deploy using standard shell tools (e.g make with Makefile).
Re:A new release for GNU Octave by f6v on Wednesday December 16, 2020 @01:38PM (#25446445)
Matlab also has toolboxes, I guess they aren’t all available in Octave?
Re:A new release for GNU Octave by 908B64B197 on Wednesday December 16, 2020 @02:02PM (#25446863)
I don't think so.

Yeah, the commercial plugins are also an interesting feature. The engineering focus of the platform makes it easier to do commercial development.

Re:A new release for GNU Octave by enriquto on Wednesday December 16, 2020 @02:52PM (#25447631)
> I don't think so.

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.

Re:A new release for GNU Octave by raoulvolfoni on Thursday December 17, 2020 @10:00AM (#25456123)
> It tends to give its users bad habits with respect to structuring code is what I observe.

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.

Re:A new release for GNU Octave by enriquto on Wednesday December 16, 2020 @11:03AM (#25444155)
> It seems to lack data structures that are quite pervasive in modern programming practise.

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.

Re:A new release for GNU Octave by leephillips on Wednesday December 16, 2020 @11:09AM (#25444222)
Except for APL!
Re:A new release for GNU Octave by ljosifov on Wednesday December 16, 2020 @01:04PM (#25445913)
In the opposite direction, being away from matlab, I notice an upside to "vectorise everything" seems to have been "code shrinkage". Looks like ~3-5x times compared to "code with loops". I often find myself ill disposed towards my (and other's) code, it looks complex and verbose. I guess one can't easily un-see/forget how much simpler things can be.
Re:A new release for GNU Octave by jsw97 on Wednesday December 16, 2020 @09:25AM (#25442812)
Amen to this. The effortless translation of matrix expressions into code is a huge positive for Matlab/Octave and negative for Python. Have not worked with Julia, and I wonder what the experience is there.
Re:A new release for GNU Octave by leephillips on Wednesday December 16, 2020 @09:48AM (#25443120)
Working with matrices is similar in Julia. In fact, the syntax was partly influenced by the desire to make it easy for MATLAB users to pick up.
Re:A new release for GNU Octave by fluidcruft on Wednesday December 16, 2020 @12:04PM (#25444979)
Do you know how difficult it is to translate Matlab into Julia? I have a bunch of Matlab code I'm needing to refresh and honestly I could go either to Python or Julia. Python is more mature, but Julia doesn't seem like it's going to die or anything.

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.

Re:A new release for GNU Octave by kwertzzz on Wednesday December 16, 2020 @04:12PM (#25448739)
I have translated quite a bit of Matlab code to Julia. Just the simple fact that indices are handled the same way in Matlab and Julia makes this transition easier than going from Matlab to Python in my opinion. What I would suggest, is that you first write some test suite of your Matlab code (you might have it already), have a look to the Julia documentation and in particular to the performance tips (https://docs.julialang.org/en/v1/manual/performance-tips/) and for functions where performance is important check its type-stability. You might want to start first with a small project to familiarize yourself with the (quite rich) type system in julia.
Re:A new release for GNU Octave by eigenspace on Wednesday December 16, 2020 @12:15PM (#25445153)
Julia is not a Matlab clone, but it does have more in common with Matlab than Python does, so translation is easier.

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.

Re:A new release for GNU Octave by fluidcruft on Wednesday December 16, 2020 @04:06PM (#25448648)
What do you mean by killing performance? Compared to Matlab implementation or compared to better Julia implementations? To me, numpy operates the same way Matlab/Octave/IDL does (slow bulky interpreter that basically orchestrates feeding/retrieving memory to fast/optimized primitives/BLAS etc). Coding in Matlab is about "vectorizing", which is also how I understand numpy to work. So to me numpy has a lot in common with Matlab conceptually in terms of how I approach implementing an algorithm.

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.

Re:A new release for GNU Octave by tikej on Wednesday December 16, 2020 @04:25PM (#25448910)
Julia isn’t as good as matlab in optimising badly written matrix code. For example some vectorised (in sense A = G(BX + CD) for matrices and vectors) it allocates temporary matrices whreas matlab is great at optimising such stuff. Most things could (and for optimal performance should) be written with loops and that will be much faster in Julia. However, there is Julia package Tullio.jl and it’s great with matrices/vectors/tensor stuff. It fuses operations, uses AVX instructions and creates code for GPU if asked.
Re:A new release for GNU Octave by eigenspace on Thursday December 17, 2020 @02:25PM (#25459297)
It can really depend. It’s certainly possible to write code in Julia that is slower than corresponding Matlab or Python code.

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.

Re:A new release for GNU Octave by fluidcruft on Friday December 18, 2020 @10:52AM (#25468219)
That's good to hear. I can usually get things to work well in matlab/octave, but it takes a lot of time thinking about how to restructure a calculation as vectorized. What I'm hearing is that with Julia I can probably just write what I mean directly and skip the pondering/iterating about how to vectorize. So I think I'll try it. Thanks!
Re:A new release for GNU Octave by leephillips on Wednesday December 16, 2020 @12:35PM (#25445500)
Not specifically, but Julia would be a better choice than Python + Numpy.
Re:A new release for GNU Octave by f6v on Wednesday December 16, 2020 @01:37PM (#25446428)
I find Julia great at linear algebra, also heard there’s some ODE support. Octave and Matlab feel outdated in comparison.
Re:A new release for GNU Octave by leephillips on Wednesday December 16, 2020 @01:47PM (#25446613)
More than some: the DifferentialEquations.jl library for Julia is one of the best for any language.
Re:A new release for GNU Octave by amkkma on Wednesday December 16, 2020 @01:47PM (#25446617)
>some ODE support

Best ODE/SDE etc support of any programming language. Including composing them with machine learning and AD, GPU, multithreading, DSLs and symbolic simplification etc

https://sciml.ai/

Re:A new release for GNU Octave by ljosifov on Friday December 18, 2020 @03:03PM (#25471255)
Looks like when making use of gazilions numbers, a single and thus minimal data structure that suffices to get the job done is a matrix is a spreadsheet is an sql table. ;-)

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.

Re:A new release for GNU Octave by Denvercoder9 on Wednesday December 16, 2020 @11:23AM (#25444401)
> use a bizarre notation (either @ or .dot look very ugly in formulas).

If you use the numpy.matrix type instead of numpy.array, the * operator becomes matrix multiplicaton.

Re:A new release for GNU Octave by enriquto on Wednesday December 16, 2020 @11:31AM (#25444510)
hmmm, I thought the matrix class was deprecated? At least it says so in the official numpy documentation:

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.

Re:A new release for GNU Octave by Denvercoder9 on Wednesday December 16, 2020 @11:36AM (#25444578)
> hmmm, I thought the matrix class was deprecated? At least it says so in the official numpy documentation:

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.

Re:A new release for GNU Octave by chollida1 on Wednesday December 16, 2020 @08:28AM (#25442235)
In finance it looks to be all but dead. 10 years ago, every fund I knew used Octave, or more likely Matlab.

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

Re:A new release for GNU Octave by ojnabieoot on Wednesday December 16, 2020 @11:17AM (#25444333)
In practice it seems like Octave isn’t a great alternative to MATLAB in industry because so many industrial customers use proprietary MathWorks packages (eg Simulink) that are missing in Octave.

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.

Re:A new release for GNU Octave by ddek on Wednesday December 16, 2020 @07:49AM (#25441901)
All anecdotes, but In my Chem degree we used MATLAB, as did all the (non software) engineers I knew. My brother is a physics PhD student in Zurich, he uses MATLAB almost exclusively.

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.

Re:A new release for GNU Octave by kxyvr on Wednesday December 16, 2020 @12:58PM (#25445836)
I work with folks in electrical controls and there's still a fair amount of modeling in Simulink. Although Octave doesn't replicate Simulink, a good amount of code is still in MATLAB. For me, I own both a MATLAB license as well as use Octave.

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.

Re:A new release for GNU Octave by BlueTemplar on Wednesday December 16, 2020 @06:50AM (#25441513)
Just one data point: in our 2nd year Masters of Computational Physics, we have :

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

Re:A new release for GNU Octave by montebicyclelo on Wednesday December 16, 2020 @06:39AM (#25441446)
Anecdotally: Some undergraduate degrees teach MATLAB, and it's the first time programming for many of the students. It is great that the students can use a FOSS alternative on their own machines. Doing the work in Python and then translating back to MATLAB would be a bit too much a stretch.

As far as I could tell, my undergraduate department ran on MATLAB (and I suspect it still does).

Re:A new release for GNU Octave by ljosifov on Wednesday December 16, 2020 @10:26AM (#25443661)
After using matlab full-time for ~15 years, as of recently I'm trying pandas/numpy/spyder because the colleagues are users. So to aid collaboration mainly, but also to try out the environment - I was curious. In matlab matrices (arrays) are 1st class citizens of the language, so having them be just another set of objects with some libraries operating on them - that feels like a step back to me. Quite a few things easy in matlab, I find less-than-easy in pandas. Hope it will get better in time. I was hoping to move from matlab to julia, but noone else I know uses it. (I do quant trading)
Re:A new release for GNU Octave by f6v on Wednesday December 16, 2020 @01:41PM (#25446517)
Multidimensional arrays are first class in Julia. Just add Linear Algebra package and you’re all set.
Re:A new release for GNU Octave by ljosifov on Thursday December 17, 2020 @06:43AM (#25454694)
Would like to try it at some point. I am trying pandas now b/c other people are using it. So far - the more I learn pandas, the less I like it. Not a good sign. I keep finding things that annoy me in pandas, b/c have seen them solved in array languages (like q/kdb) and matlab.
Re:A new release for GNU Octave by f6v on Thursday December 17, 2020 @01:33PM (#25458619)
Yeah Julia is more popular in research than in industry. Python dominates data science field, but I as well find pandas and other tools too clunky.
Re:A new release for GNU Octave by ImprovedSilence on Wednesday December 16, 2020 @08:37AM (#25442307)
I often find myself wondering what the field at large is using. I still use matlab daily in my job (signal processing), and have octave on my personal laptop. Ive played w/ the anaconda/spyder/scipi/numpi suite on my own a bit, mostly cuz it seems thats gotten some momentum, but i dont have a big use for it outside work. We are pretty deep in having a lot of tooling built up in matlab, and i dont see us leaving it anytime soon, and to be honest, I love it, probably cuz thats what im most proficient at.
Re:A new release for GNU Octave by jacksonkmarley on Wednesday December 16, 2020 @09:56AM (#25443234)
I'm interested to know how you rate the matlab alternatives on interacting visually with the data? I often want to do things in Matlab like plot a largeish data set, then zoom in to different features, or open an array of data in a window and check values. How is octave for that sort of thing? How about python?
Re:A new release for GNU Octave by alexhutcheson on Wednesday December 16, 2020 @01:49PM (#25446651)
Octave is ok for that, but not as good as Matlab. All the Matlab plotting functions work, but the plots don't look as nice, and require more tweaking to get them to "publication quality". Octave includes a Qt-based GUI, but it is not nearly as polished as the Matlab GUI.

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.

[1] https://matplotlib.org/

[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/

[7] https://dplyr.tidyverse.org/

[8] https://r4ds.had.co.nz/

[9] https://rstudio.com/products/rstudio/

Re:A new release for GNU Octave by jacksonkmarley on Wednesday December 16, 2020 @06:22PM (#25450157)
Hey, thanks for the great detailed answer!
Re:A new release for GNU Octave by analog31 on Wednesday December 16, 2020 @08:35AM (#25442295)
I work in a small industrial R&D group that was using a hodgepodge of Excel, Visual Basic, C, and an outdated MATLAB license. I switched from VB to Python, and the rest of the group has followed suit.

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.

Re:A new release for GNU Octave by qnzy on Wednesday December 16, 2020 @06:46AM (#25441488)
I'm not sure how relevant it is. I use it almost everyday (EE). For me it basically serves as my (very advanced) calculator. If my scripts get above a certain complexity, I'll move to Python, but for smaller things I much prefer Octave.
Re:A new release for GNU Octave by signaru on Wednesday December 16, 2020 @07:53AM (#25441922)
A few reasons: legacy code in research (often headed by older staff), Matlab's speed out of the box, use in industry (Toyota), and toolboxes developed by Mathworks itself. For those who don't want to resort to piracy when doing "home work", Octave is a really good alternative for less complex scripts.
Re:A new release for GNU Octave by panpanna on Wednesday December 16, 2020 @06:52AM (#25441532)
Our university paid top dollar for Matlab site licenses. Nowadays students mostly use octave.

Termux is such a lovely project. Works also great on chromebooks and chromebook tablets.

Re:A new release for GNU Octave by alexhutcheson on Wednesday December 16, 2020 @08:48AM (#25442405)
Many Chromebooks and Chromebook tablets now have a real Linux environment available: https://support.google.com/chromebook/answer/9145439
Re:A new release for GNU Octave by curt15 on Wednesday December 16, 2020 @07:04AM (#25441608)
Couldn't this be used by Mathworks against Octave if SCOTUS rules that reimplementing APIs is a copyright violation?
Re:A new release for GNU Octave by panpanna on Wednesday December 16, 2020 @08:15AM (#25442103)
Mate, octave getting sued would be the least of my worries if supereme court rules that way...
Re:A new release for GNU Octave by sudosysgen on Wednesday December 16, 2020 @12:47PM (#25445687)
Is Octave based in the US?
Re:A new release for GNU Octave by Jenz on Wednesday December 16, 2020 @08:15AM (#25442104)
> Since it seems researchers are migrating away from MATLAB itself to python (numpy/scipy).

... and from python (numpy/scipy) to Julia

Re:A new release for GNU Octave by michaelcampbell on Wednesday December 16, 2020 @08:50AM (#25442413)
I'm sure some are, sure, but I bet the vast majority of researchers: a) are still using python + libs b) that ARE changing from something to something else are moving to python from not-python