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

131–140 of 174 posts

Re: In Defense of Matlab Code

#131

Post by pbowyer »

SatvikBeri wrote: post #33
drnick1 wrote: post #15

Earlier quoted context omitted.

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…

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

> Part of our interview process is a take-home where we ask candidates to build the fastest version of a pipeline they possibly can. People usually use C++ or Julia. All of the fastest answers are in Julia.

It would be fun if you could share a similar pipeline problem to your take-home (I know you can't share what's in your interview). I started off in scientific Python in 2003 and like noodling around with new programming languages, and it's great to have challenges like this to work through. I enjoyed the 1BRC problem in 2024.

Re: In Defense of Matlab Code

#132

Post by stared »

On the contrary, I think that well-designed general-purpose languages beat domain-specific languages. Even in the example given, in NumPy you can use np.array, but to make a fair comparison, use np.matrix.

  import numpy as np
  
  X = np.matrix([1, 2, 3])
  Y = np.matrix([[1, 2, 3],
                 [4, 5, 6],
                 [7, 8, 9]])
  
  Z = Y * X.T
  W = np.hstack([Z, Z])
That way, we can extend our languages. If np.matrix is "too many keystrokes", it can be imported as M, or similar.

X.T is as readable as X' - but on top of that, also extensible. If we want to add other operations, we can do so. Especially since transpose is a very limited operation: it only makes sense for vectors and matrices. In much of numerics (quantum physics, deep learning, etc.), we often work with tensors. For example, within matrix notation, I would expect [Z, Z] to create a tensor, not concatenate matrices.

To make it clear, I agree with the main premise that it is important to make math readable, and thus easy to read and debug. Otherwise, it is one of the worst places for errors (numbers in, numbers out).

When it comes to matrix notation, I prefer PyTorch over NumPy, as it makes it easy to go from math on a whiteboard to executable code (see https://github.com/stared/thinking-in-tensors-writing-in-pyt...).

Also, for rather advanced custom numerics in quantum computing, I used Rust. To my surprise, not only was it fast, but thanks to macros, it was also succinct.

Re: In Defense of Matlab Code

#133

Post by forgotpwd16 »

wolvesechoes wrote: post #126
sundarurfriend wrote: post #23

Earlier quoted context omitted.

As your comment already hints at, using Python often ends up a hodgepodge of libraries and tools glued together, that work for their limited scope but show their shaky foundations any time your work is outside of those parts. Having worked with researchers and engineers for years on their codebases, there is already too much "throw shit at the wall and see what sticks" temptation in this type of code (because they'd…

> using Python often ends up a hodgepodge of libraries and tools glued together At least it has those tools and libraries, what cannot be said about Julia.

What tools/libraries you miss from Julia? Have you used the language or merely speculating?

Re: In Defense of Matlab Code

#134

Post by KingMob »

D-Machine wrote: post #107
KingMob wrote: post #102

Ehhh, as someone who did cognitive neuroscience in grad school and wrote non-stop Matlab 20 years ago, this is correct but insufficient. The toolbox and licensing situation sucked, but that's not why I hated it. At the time, we had massive issues with using Matlab with large fMRI/EEG/MEG data sets, and attempts to write naive matrix-based versions of code would occasionally blow up memory consumption, and turn a 3-we…

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

Re: In Defense of Matlab Code

#135

Post by torginus »

Personally I haven't used Matlab since college (EE), and I haven't really done those EE things since then. But man, Matlab was indispensable (control loop design, system identification, all sorts of signal processing and E&M stuff).

One of the best things about Matlab was that it had an absolutely enormous library of tools, I could reasonably do everything I wanted, and more importantly, all the notation and convention matched what was used in EE, so I could easily translate whitepapers, and my own and others' calculations into code.

In scientific computing, each disciple has their own preferred way of writing things, so a system identification problem might be stated completely differently by a power engineer, a communications engineer, and a physicist, and deciphering each others' formulas and notations often is just as difficult as understanding the core point of the paper.

That's why a lot of math packages, which were written by academic physicists for other physicists were essentially impossible to use for EEs, and Matlab actually adopting the EE conventions was a godsend, even if it was proprietary.

As a programming language, I didn't like/hate it that much, I guess if I tried to develop an application suite in it like many others did, I'd have had an awful time, but for the simple stuff (in terms of programming) I did with it, it was fine.

Re: In Defense of Matlab Code

#136

Post by mgkuhn »

The problem with MATLAB is that idiomatic MATLAB style (every operation returns a fresh matrix) can easily become very inefficient: it leads to countless heap memory allocations of new matrices, resulting in low data-access locality, i.e. your data is needlessly copied around in slow DRAM all the time, rather than being kept in the fastest CPU cache.

Julia's MATLAB-inspired syntax is at least as nice, but the language was from the ground up designed to enable you writing high-performance code. I have seen numerous cases where code ported from MATLAB or NumPy to Julia performed well over an order of magnitude faster, while often also becoming more readable at the same time. Julia's array-broadcast facilities, unparalleled in MATLAB, are just reason for that. The ubiquitous availability of in-place update versions of standard library methods (recognizable by an ! sign) is another one.

In our group, nobody has been using MATLAB for nearly a decade, and NumPy is well on its way out, too. Julia simply has become so much more productive and pleasant to work with.

https://julialang.org/

https://docs.julialang.org/en/v1/manual/noteworthy-differenc...

Re: In Defense of Matlab Code

#137

Post by Alexander-Barth »

nallana wrote: post #19
mNovak wrote: post #12

As an engineer, I use Matlab (or rather, Octave the free equivalent) all the time. It's really great for numerical computing and plotting. Most things 'just work', there's a sizeable collection of packages, and I personally like how flexible the function inputs are. Biggest drawback though is that it's over-optimized for matrix math, that it forces you to think about everything as matrices, even if that's not how you…

@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…

I wish you all the best luck with your product!

Unfortunately, mathworks is a quite litigious company. I guess you are aware of mathworks versus AccelerEyes (now makers of ArrayFire) or Comsol.

For our department, we mostly stop to use MATLAB about 7 years ago, migrating to python, R or Julia. Julia fits the "executable math" quite well for me.

Re: In Defense of Matlab Code

#138

Post by mgkuhn »

stared wrote: post #132

On the contrary, I think that well-designed general-purpose languages beat domain-specific languages. Even in the example given, in NumPy you can use np.array, but to make a fair comparison, use np.matrix. import numpy as np X = np.matrix([1, 2, 3]) Y = np.matrix([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) Z = Y * X.T W = np.hstack([Z, Z]) That way, we can extend our languages. If np.matrix is "too many keystrokes", it can be…

In Julia:

  X = [1 2 3]
  Y = [1 2 3;
       4 5 6;
       7 8 9]

  Z = Y * X'
  W = hcat(Z, Z)

Re: In Defense of Matlab Code

#139

Post by wiz21c »

mgkuhn wrote: post #138
stared wrote: post #132

On the contrary, I think that well-designed general-purpose languages beat domain-specific languages. Even in the example given, in NumPy you can use np.array, but to make a fair comparison, use np.matrix. import numpy as np X = np.matrix([1, 2, 3]) Y = np.matrix([[1, 2, 3], [4, 5, 6], [7, 8, 9]]) Z = Y * X.T W = np.hstack([Z, Z]) That way, we can extend our languages. If np.matrix is "too many keystrokes", it can be…

In Julia: X = [1 2 3] Y = [1 2 3; 4 5 6; 7 8 9] Z = Y * X' W = hcat(Z, Z)

It's been long since I've heard of Julia. It seems it has hard times picking up steam... Any news ? (yeah, I check the releases and the juliabloggers site)

Re: In Defense of Matlab Code

#140

Post by fluidcruft »

Alexander-Barth wrote: post #137
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…

I wish you all the best luck with your product! Unfortunately, mathworks is a quite litigious company. I guess you are aware of mathworks versus AccelerEyes (now makers of ArrayFire) or Comsol. For our department, we mostly stop to use MATLAB about 7 years ago, migrating to python, R or Julia. Julia fits the "executable math" quite well for me.

All anyone really needs is seamless integration of Julia with python. Instead everyone seems to be rewriting python into rust.
Post reply on HN