Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In Defense of Matlab Code

runmat.org

Post reply on HN
Print view View original

111–120 of 174 posts

Re: In Defense of Matlab Code

#111

Post by drnick1 »

doawoo wrote: post #90

I want to come out and say that a long time ago at a startup we needed to generate a very particular type of analysis graph for a human operator to review in our SaaS. and I just straight up installed GNU Octave on the server and called out to it from python, using the exact code the mathematician had devised.

These days however with all the AI coding tools that are available, it probably makes more sense to just ask Claude to port the Matlab/Octave script to Python and directly integrate it into your program. Numpy/Scipy often provide drop-in replacements for Matlab functions, even the names are the same in some cases.

I have gone further and asked AI to port working but somewhat slow numerical scripts to C++ and it's completely effortless and very low risk when you have the original implementation as test.

Re: In Defense of Matlab Code

#112

Post by faustlast »

D-Machine wrote: post #108

Defending Matlab code in 2025 is like defending Emacs: it's not that you don't have logically good points, in many cases, it is just that you are so completely out of touch with modern advances, communities, and requirements that it isn't even clear that you are speaking to anything more than what amounts to a rounding error. EDIT: Specifically, it is extremely hard for me to think that anyone should be convinced to…

> Defending Matlab code in 2025 is like defending Emacs

I feel attacked.

Re: In Defense of Matlab Code

#113

Post by D-Machine »

faustlast wrote: post #112
D-Machine wrote: post #108

Defending Matlab code in 2025 is like defending Emacs: it's not that you don't have logically good points, in many cases, it is just that you are so completely out of touch with modern advances, communities, and requirements that it isn't even clear that you are speaking to anything more than what amounts to a rounding error. EDIT: Specifically, it is extremely hard for me to think that anyone should be convinced to…

> Defending Matlab code in 2025 is like defending Emacs I feel attacked.

LOL. My friend, I sympathize deeply, and this was not the intention.

Re: In Defense of Matlab Code

#114

Post by adgjlsfhk1 »

quietbritishjim wrote: post #110
BobbyTables2 wrote: post #84

Earlier quoted context omitted.

What does it even mean to add a 1x3 matrix to a 3x1 matrix ?

It means the same thing in MATLAB and numpy: Z = np.array([[1,2,3]]) W = Z + Z.T print(W) Gives: [[2 3 4] [3 4 5] [4 5 6]] It's called broadcasting [1]. I'm not a fan of MATLAB, but this is an odd criticism. [1] https://numpy.org/devdocs/user/basics.broadcasting.html#gene...

One of the really nice things Julia does is make broadcasting explicit. The way you would write this in Julia is

    Z = [1,2,3]

    W = Z .+ Z' # note the . before the + that makes this a broadcasted
This has 2 big advantages. Firstly, it means that users get errors when the shapes of things aren't what they expected. A DimmensionMismatch error is a lot easier to debug than a silently wrong result. Secondly, it means that julia can use `exp(M)` etc to be a matrix exponential, while the element-wise exponential is `exp.(M)`. This allows a lot of code to naturally work generically over both arrays and scalars (e.g. exp of a complex number will work correctly if written as a 2x2 matrix)

Re: In Defense of Matlab Code

#115

Post by D-Machine »

esalman wrote: post #85
gdevenyi wrote: post #58

No. Just no. Terrible HPC integration. Proprietary runtime.

I worked at three large universities where folks ran Matlab processes on HPC all the time.

"I have direct experience of universities doing horrifyingly wasteful computations" is not the ringing endorsement for Matlab you might think it to be...

Granted, I've seen Python horrors on university HPC clusters too, but at least there are libraries and clear documentation (e.g. Lightning, Ray, etc) for how to properly manage these things. Good luck finding that with Matlab.

Re: In Defense of Matlab Code

#116

Post by adgjlsfhk1 »

sbrother wrote: post #106
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.…

> People usually use C++ or Julia. All of the fastest answers are in Julia That's surprising to me and piques my interest. What sort of pipeline is this that's faster in Julia than C++? Does Julia automatically use something like SIMD or other array magic that C++ doesn't?

The main thing is just that Julia has a standard library that works with you rather than working against you. The built in sort will use radix sort where appropriate and a highly optimized quicksort otherwise. You get built in matrices and higher dimensional arrays with optimized BLAS/LaPack configured for you (and CSC+structured sparse matrices). You get complex and rational numbers, and a calling convention (pass by sharing) which is the fast one by default 90% of the time instead of being slow (copying) 90% of the time. You have a built in package manager that doesn't require special configuration, that also lets you install GPU libraries that make it trivial to run generic code on all sorts of accelerators.

Everything you can do in Julia you can do in C++, but lots of projects that would take a week in C++ can be done in an hour in Julia.

Re: In Defense of Matlab Code

#117

Post by D-Machine »

quietbritishjim wrote: post #105
themeiguoren wrote: post #40

Of the things matlab has going for it, looking just like the math is pretty far down the list. Numpy is a bit more verbose but still 1-to-1 with the whiteboard. The last big pain point was solved ( https://peps.python.org/pep-0465/ ) with the dedicated matmul operator in python 3.5. Real advantages of matlab: * Simulink * Autocoding straight to embedded * Reproducible & easily versioned environment * Single-source de…

> Big disadvantages of matlab: I will add to that: * it does not support true 1d arrays; you have to artificially choose them to be row or column vectors. Ironically, the snippet in the article shows that MATLAB has forced them into this awkward mindset; as soon as they get a 1d vector they feel the need to artificially make it into a 2d column. (BTW (Y @ X)[:,np.newaxis] would be more idiomatic for that than Y @ X.r…

* it does not support true 1d arrays; you have to artificially choose them to be row or column vectors.

I despise Matlab, but I don't think this is a valid criticism at all. It simply isn't possible to do serious math with vectors that are ambiguously column vs. row, and this is in fact a constant annoyance with NumPy that one has to solve by checking the docs and/or running test lines on a REPL or in a debugger. The fact that you have developed arcane invocations of "[:,np.newaxis]" and regular .reshape calls I think is a clear indication that the NumPy approach is basically bad in this domain.

You do actually need to make a decision on how to handle 0 or 1-dimensional vectors, and I do not think that NumPy (or PyTorch, or TensorFlow, or any Python lib I've encountered) is particularly consistent about this, unless you ingrain certain habits to always call e.g. .ravel or .flatten or [:, :, None] arcana, followed by subsequent .reshape calls to avoid these issues. As much as I hated Matlab, this shaping issue was not one I ran into as immediately as I did with NumPy and Python Tensor libs.

EDIT: This is also a constant issue working with scikit-learn, and if you regularly read through the source there, you see why. And, frankly, if you have gone through proper math texts, they are all extremely clear about column vs row vectors and notation too, and all make it clear whether column vs. row vector is the default notation, and use superscript transpose accordingly. It's not that you can't figure it out from context, it is that having to figure it out and check seriously damages fluent reading and wastes a huge amount of time and mental resources, and terrible shaping documentation and consistency is a major sore point for almost all popular Python tensor and array libraries.

Re: In Defense of Matlab Code

#119

Post by jakobnissen »

sbrother wrote: post #106
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.…

> People usually use C++ or Julia. All of the fastest answers are in Julia That's surprising to me and piques my interest. What sort of pipeline is this that's faster in Julia than C++? Does Julia automatically use something like SIMD or other array magic that C++ doesn't?

I use Rust instead of C++, but I also see my Julia code being faster than my Rust code.

In my view, it's not that Julia itself is faster than Rust - on the contrary, Rust as a language is faster than Julia. However, Julia's prototyping, iteration speed, benchmarking, profiling and observability is better. By the time I would have written the first working Rust version, I would have written it in Julia, profiled it, maybe changed part of the algorithm, and optimised it. Also, Julia makes more heavy use of generics than Rust, which often leads to better code specialization.

There are some ways in which Julia produces better machine code that Rust, but they're usually not decisive, and there are more ways in which Rust produces better machine code than Julia. Also, the performance ceiling for Rust is better because Rust allows you to do more advanced, low level optimisations than Julia.

Re: In Defense of Matlab Code

#120

Post by jakobnissen »

drnick1 wrote: post #15
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.

I don't think Julia really solves any problems that aren't already solved by Python. Python is sometimes slower (hot loops), but for that you have Numba. And if something is truly performance critical, it should be written or rewritten in C++ anyway. But Julia also introduces new problems, such as JIT warmup (so it's not really suitable for scripting) and is still not considered trustworthy: https://yuri.is/not-julia…

Yes, Python code is indeed fast if you write it in C++... what a bizarre argument. The whole selling point of Julia is that I can BOTH have a dynamic language with a REPL, where I can redefine methods etc, AND that it runs so fast there is no need to go to another language.

It's wild what people get used to. Rustaceans adapt to excruciating compile times and borrowchecker nonsense, and apparently Pythonistas think it's a great argument in favor of Python that all performance sensitive Python libraries must be rewritten in another language.

In fairness, we Julians have to adapt to a script having a 10 second JIT latency before even starting...

Post reply on HN