In Defense of Matlab Code • Hacker News Board

Re: In Defense of Matlab Code

#161

Post by D-Machine » Tue, Dec 16, 2025, 6:46 PM UTC

KingMob wrote: post #134

D-Machine wrote: post #107

Earlier quoted context omitted.

Have to agree, working with fMRI and MRI data. Matlab is nearly impossible to debug or even find basic workarounds for problems in this domain, in comparison to Python, because of how closed and niche Matlab is, and the lack of community and trustworthy documentation, or ability to write sensible code with performant for loops. In my experience, those arguing for the value of Matlab are mostly 50+ years old, or are i…

> It is a smell for incompetent legacy research in this domain. Wild to hear. At the time, almost everybody in the field used it. The then-dominant fMRI package (SPM) and EEG/MEG package (Fieldtrip) were both open-source Matlab. (I think I knew one prof who used BrainVoyager, and that's because he hired a former BV employee as an RA.)

"At the time" being key here, yes. SPM is a red flag now.

Re: In Defense of Matlab Code

#162

Post by esalman » Tue, Dec 16, 2025, 7:48 PM UTC

D-Machine wrote: post #160

esalman wrote: post #159

Earlier quoted context omitted.

To find the goalpost look at the parent comment of the one you first saw.

Sorry if I was unclear, but GP is correct, you are misreading quite deeply. I am saying that because it is much harder to find good documentation on using MATLAB on HPCs, a lot of computations on HPCs that use MATLAB are highly wasteful compared to if they had been written using a language and/or tools that make it much easier to use HPC resources more efficiently. I was NOT in any way saying that "universities are w…

Fair. My point though is that in scientific research, accuracy of the results come first. It does not mean anything that research was performed efficiently if the results are incorrect.

Re: In Defense of Matlab Code

#163

Post by postflopclarity » Tue, Dec 16, 2025, 10:16 PM UTC

drnick1 wrote: post #109

SatvikBeri wrote: post #33

Earlier quoted context omitted.

> Python is sometimes slower (hot loops), but for that you have Numba This is a huge understatement. At the hedge fund I work at, I learned Julia by porting a heavily optimized Python pipeline. Hundreds of hours had gone into the Python version – it was essentially entirely glue code over C. In about two weeks of learning Julia, I ported the pipeline and got it 14x faster. This was worth multiple senior FTE salaries.…

The C++ devs at your firm must be absolutely terrible if a newcomer using a scripting language can write faster software, or you are not telling the whole story. All of NumPy, Julia, MATLAB, R, and similar domain-specific, user-friendly libraries and platforms use BLAS and LAPACK for numerical calculations under the hood with some overhead depending on the implementation, so a reasonably optimized native implementati…

Julia is not a scripting language and can match C performance on many tasks.

Re: In Defense of Matlab Code

#164

Post by D-Machine » Tue, Dec 16, 2025, 11:57 PM UTC

esalman wrote: post #162

D-Machine wrote: post #160

Earlier quoted context omitted.

Sorry if I was unclear, but GP is correct, you are misreading quite deeply. I am saying that because it is much harder to find good documentation on using MATLAB on HPCs, a lot of computations on HPCs that use MATLAB are highly wasteful compared to if they had been written using a language and/or tools that make it much easier to use HPC resources more efficiently. I was NOT in any way saying that "universities are w…

Fair. My point though is that in scientific research, accuracy of the results come first. It does not mean anything that research was performed efficiently if the results are incorrect.

I dunno, since research has to be funded, and typically HPC clusters also have to allocate compute resources, the clunkiness of things like MATLAB actually does translate to wasted and inefficient funding.

All other things being equal, suppose two research programs are proposing to study roughly the same thing (say, some novel optimization or basic stuff on something like simple neural networks; and let's pretend this is some years ago when people still actually reached for MATLAB neural net tools). If both request significant compute allocations, and I see one is planning on MATLAB, and the other on PyTorch Lightning, I know for sure I would want to give the MATLAB users far less funding, or even none at all, since they're really going to struggle to properly leverage the CPUs and GPUs available to them, whereas the Lightning people will largely just have this work immediately, and almost certainly be able to iterate faster and be more likely to find something meaningful.

It's a contrived and unfair example, and in practice the real problem is actually the annoying MATLAB licensing mostly, but also it really is a fact that MATLAB screws up even basic stuff in HPC environments (see e.g. https://docs.alliancecan.ca/wiki/MATLAB#Simultaneous_paralle...).

Re: In Defense of Matlab Code

#165

Post by markkitti » Wed, Dec 17, 2025, 2:08 AM UTC

zackmorris wrote: post #158

nallana wrote: post #19

Earlier quoted context omitted.

@mNovak -- super helpful note! Thank you! Author of RunMat (this project) here -- > The first thing they teach about performant Matlab code is that simple for-loops will tank performance. Yes! Since in RunMat we're building a computation graph and fusing operations into GPU kernels, we built the foundations to extend this to loop fusion. That should allow RunMat to take loops as written, and unwrap the matrix math in…

Piggybacking also to say that I hope you succeed, as your work aligns closely with the type of runtime that I had hoped to write someday when I first used MATLAB in the early 2000s (now mostly GNU Octave for small hobby projects). The loop fusion idea sounds amazing. Another point of friction which I ran into is that MATLAB uses 1-based offsets instead of 0-based offsets for matrices/arrays, which can make porting co…

> I wish there was a way to specify the offset base with something like a C #define or compiler directive.

Julia has OffsetArrays.jl implementing arbitrary-base indexing: https://juliaarrays.github.io/OffsetArrays.jl/stable/

The experience with this has been quite mixed, creating a new surface for bugs to appear. Used well, it can be very convenient for the reasons you state.

  julia> A = collect(1:5)
  5-element Vector{Int64}:
   1
   2
   3
   4
   5

  julia> B = OffsetArray(A, -1)
  5-element OffsetArray(::Vector{Int64}, 0:4) with eltype Int64 with indices 0:4:
   1
   2
   3
   4
   5

  julia> A[1]
  1

  julia> B[0]
  1

Re: In Defense of Matlab Code

#166

Post by cstarkjp » Wed, Dec 17, 2025, 2:25 AM UTC

Having spent a lifetime in both science and engineering departments, I can safely say that the persistent use of Matlab is almost entirely because of entrenchment: the professors learned Matlab, they don't have time/energy/interest to learn a better alternative, and so they use it in their teaching, and the next generation carries the leaden baton onwards. Syntax has very little to do with it; runtime speed has little to do with it; development speed is why it was adopted in parallel with system languages in the first place.

The OP's argument is weakened a little by their Python, which could be simpler (here X is now a 3x1 column "vector"):

   X = np.array([[1, 2, 3]]).T
   Y = np.array([[1, 2, 3],
                 [4, 5, 6],
                 [7, 8, 9]])
   Z = Y @ X
   np.hstack((X, X))

which is almost as readable as the Matlab (and let's not forget those semi-colons and ellipses are awkward too).

The OP mentions "Licensing Pain" without citing the high price of a Matlab license: the issues they mention are real (license server not behaving; shared license not available), but the true problem is that in many parts of the world, the money just isn't there. So people use cracked licenses instead.

As a professor, it makes me wildly uncomfortable to see my colleagues inculcate in the next generation of engineers a lifetime dependence on an expensive, closed-source, commercial product. Free alternatives like Octave and RunMat are nice, but niche: in that respect, I wish the RunMat project the best of luck. I very much hope they don't get targeted by MathWorks lawyers.

Re: In Defense of Matlab Code

#167

Post by esalman » Wed, Dec 17, 2025, 3:05 AM UTC

D-Machine wrote: post #164

esalman wrote: post #162

Earlier quoted context omitted.

Fair. My point though is that in scientific research, accuracy of the results come first. It does not mean anything that research was performed efficiently if the results are incorrect.

I dunno, since research has to be funded, and typically HPC clusters also have to allocate compute resources, the clunkiness of things like MATLAB actually does translate to wasted and inefficient funding. All other things being equal, suppose two research programs are proposing to study roughly the same thing (say, some novel optimization or basic stuff on something like simple neural networks; and let's pretend thi…

> If both request significant compute allocations, and I see one is planning on MATLAB, and the other on PyTorch Lightning, I know for sure I would want to give the MATLAB users far less funding, or even none at all

I want to say the least offensive way possible that I really do hope you do not ever get to review NSF/NIH grants because of bias like this.

The example that you gave is/was also a solved problem in the HPC systems I used. SLURM/PBS, when properly configured, can ensure that local clusters do not spill over and not use resources that are not supposed to be used.

Re: In Defense of Matlab Code

#168

Post by D-Machine » Wed, Dec 17, 2025, 4:35 AM UTC

esalman wrote: post #167

D-Machine wrote: post #164

Earlier quoted context omitted.

I dunno, since research has to be funded, and typically HPC clusters also have to allocate compute resources, the clunkiness of things like MATLAB actually does translate to wasted and inefficient funding. All other things being equal, suppose two research programs are proposing to study roughly the same thing (say, some novel optimization or basic stuff on something like simple neural networks; and let's pretend thi…

> If both request significant compute allocations, and I see one is planning on MATLAB, and the other on PyTorch Lightning, I know for sure I would want to give the MATLAB users far less funding, or even none at all I want to say the least offensive way possible that I really do hope you do not ever get to review NSF/NIH grants because of bias like this. The example that you gave is/was also a solved problem in the H…

I picked an intentionally contrived case where MATLAB is undeniably a really bad choice here. Most real world situations are not so ridiculous and would not justify such a simple decision, but if you can't see that MATLAB wouldn't be a horrible choice in this specific contrived situation, I would suggest it is in fact you who has the bias. I agree in general anyone making funding decisions solely based on MATLAB vs. other is not to be trusted, but that is NOT the situation I so carefully presented.

And yes, clearly, based on what I linked, this MATLAB issue is a solved problem on Canadian SLURM HPC clusters too. It's just, so much more is solved by e.g. modern Python libs like Ray, Lighting, and etc., it is really silly to pretend that MATLAB users can as easily make as good use of HPC clusters as everyone else can, especially today if GPUs are involved.

I'm still going to upvote you here because I think you are engaging honestly and fairly, and we just generally disagree here.

Re: In Defense of Matlab Code

#169

Post by fph » Wed, Dec 17, 2025, 9:04 AM UTC

freehorse wrote: post #81

fph wrote: post #7

Earlier quoted context omitted.

Precisely; today Julia already solves many of those problems. It also removes many of Matlab's footguns like `[1,2,3] + [4;5;6]`, or also `diag(rand(m,n))` doing two different things depending on whether m or n are 1.

Why is the `[1,2,3] + [4;5;6]` syntax a footgun? It is a very concise, comprehensible and easy way to create matrices in many cases. Eg if you have a timeseries S, then `S - S'` gives all the distances/differences between all its elements. Or you have 2 string arrays and you want all combinations between the two. The diag is admittedly unfortunate and it has confused me myself, it should actually be 2 different funct…

What happens most of the time with unexperienced or distracted users is that they write things like `norm(S - T)` to compute how close two vectors are, but one of them is a row vector and the other is a column vector, so the result is silently completely wrong.

Matlab's functions like to create row vectors (e.g., linspace) in a world where column vectors are more common, so this is a common occurrence.

So `[1,2,3] + [4;5;6]` is a concise syntax for an uncommon operation, but unfortunately it is very similar to a frequent mistake for a much more common operation.

Julia tells the two operations (vector sum and outer sum) apart very elegantly: one is `S - T` and the other is `S .- T`: the dot here is very idiomatic and consistent with the rest of the syntax.

Re: In Defense of Matlab Code

#170

Post by h3half » Wed, Dec 17, 2025, 10:54 AM UTC

boscillator wrote: post #151

nallana wrote: post #22

Earlier quoted context omitted.

Yep! Makes sense. Though I think the cost of writing these toolboxes is lim --> 0. Will have a really solid rust inspired package manager soon, and a single #macro to expose a rust function in the RunMat script's namespace (= easy to bring any aspects of the rust ecosystem to RunMat).

I wouldn't be so sure that writing those toolboxes is cheap. You need an aerospace engineer to write the aero toolbox, or you are going to miss subtleties. I assume you need a biologist to write the biology toolboxes. All of these domain experts are really expensive, and I would not trust a toolbox that hadn't been review by them.

Even then... the reason we use the aero toolbox is because everybody in the aero industry trusts that MATLAB's results are accurate. I don't need to prove that the ECEFKeplerian conversions are correct, I can just show that I'm using the toolbox function and people assume it's correct. The aero toolbox is trusted.

When I've had to write similar code in Python, it's a massive pain to "prove" that my conversation code is correct. Often I've resorted to using MATLAB's trusted functions to generate "truth" data and then feeding that to Python to verify it gets the same results.

Obviously this is more work than just using the premade stuff that comes with the toolbox.

Any MATLAB alternative faces the same trust issue. Until it reaches enough mindshare that people assume that it's too popular to have incorrect math (which might not be a good assumption but it is one that people make about MATLAB) then it doesn't actually mimic the main benefit of MATLAB which is that I don't need to check its work.