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

71–80 of 174 posts

Re: In Defense of Matlab Code

#71

Post by dkarl »

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…

Piggybacking on this comment to say, I bet a lot of people's first question will be, why aren't you contributing to Octave instead of starting a new project? After reading this declaration of the RunMat vision, the first thing I did was ctrl-f Octave to make sure I hadn't missed it.

Honest question, Octave is an old project that never gained as much traction as Julia or NumPy, so I'm sure it has problems, and I wouldn't be surprised if you have excellent reasons for starting fresh. I'm just curious to hear what they are, and I suspect you'll save yourself some time fielding the same question over and over if you add a few sentences about it. I did find [1] on the site, and read it, but I'm still not clear on if you considered e.g. adding a JIT to Octave.

[1] https://runmat.org/blog/matlab-alternatives

Re: In Defense of Matlab Code

#72

Post by hatmatrix »

constantcrying wrote: post #24

What a terrible article. The author does not understand matlab at all and he is also either lying or totally clueless. Matlab is successful because of precisely one thing, which nobody has replicated. It offers a complete software environment from one source. Nowhere else can you get scientific computing, a GUI toolkit, a high level embedded software environment, a HiL/SiL toolkit, a model based simulation environmen…

How about fft? If you open fft.m, you get just a commented file that ends with

% Built-in function.

If the algorithm is implemented as a compiled mex function, then you cannot inspect its details.

Re: In Defense of Matlab Code

#73

Post by hatmatrix »

nallana wrote: post #46
constantcrying wrote: post #42

Earlier quoted context omitted.

I explicitly pointed out what the article was lying about. "You cannot see how fft or ode45 are implemented under the hood." is a totally false statement. You absolutely can do exactly that. This is not a matter of opinion. Right click the function and open it, you can view it like any other matlab function. > From perspective of open / closed source -- maybe for you it qualifies as open source Matlab is obviously no…

Seeing in MATLAB code how ode45 is implemented != how the thing is running on the machine. That's a very small top slice. But okay -- as I mentioned, you're entitled to your views!

fft.m is the more obvious example of the closed source algorithm here. You open it and it just says

% Built-in function.

The algorithms written in C and compiled by mex are the "built-in" ones that are not viewable.

Re: In Defense of Matlab Code

#74

Post by kiernanroche »

I went to college a few miles from Mathworks's global headquarters.

They came to speak at my school and described open source alternatives (Python in particular) as the biggest threat to MATLAB.

I think if they open-sourced the MATLAB runtime and embraced a model similar to Canonical or Red Hat where users paid for support or integrations, they'd make more money. But it's hard to get there from where they are now.

Re: In Defense of Matlab Code

#75

Post by amluto »

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…

> Autocoding straight to embedded

I used this twenty-something years ago. It worked, but I would not have wanted to use it for anything serious. Admittedly, at the time, C on embedded platforms was a truly awful experience, but the C (and Rust, etc) toolchain situation is massively improved these days.

> Plotting still better than anything else

Is it? IIRC one could fairly easily get a plot displayed on a screen, but if you wanted nice vector output suitable for use in a PDF, the experience was not enjoyable.

Re: In Defense of Matlab Code

#76

Post by hatmatrix »

finbarr1987 wrote: post #57
tpoacher wrote: post #55

One small piece of feedback for the dev, since I see you've been replying to comments here. I had to jump like 3 links and 4 pages down to figure out what runmat actually "is" / "does". As someone who's done their whole thesis using Octave this looks interesting. I love Octave, it's one of my favourite languages. And, for reasons I don't understand even myself, I don't like matlab that much (though I admit their docu…

Thanks for digging in ;) We just released RunMat in August as an open-source, fast MATLAB runtime. The goal is to make it the fastest way to run math, period. Coming from Octave, you'll notice significant speedup advantages, you can see some of our benchmarks with it here https://runmat.org/blog/introducing-runmat Last month, we put out 250+ built-in functions and Accelerate, which fuses operations and routes between…

What's the business model?

Re: In Defense of Matlab Code

#77

Post by hatmatrix »

ChaitanyaPatel wrote: post #31

For MATLAB, there exist many high quality free and/r open source toolboxes from community and academia. Also there are high quality free and/or open source alternatives. GNU Octave https://octave.org and Octave online https://octave-online.net/ Freemat https://freemat.sourceforge.net/ (sadly no ongoing development) Scilab https://www.scilab.org/ and Scilab online https://cloud.scilab.in/

Indeed, there are many high-quality alternatives (sometimes described as "MATLAB clones" back in the day) that never gained bigger traction.

Among modern alternatives that don't strictly follow MATLAB syntax, Julia has the biggest mindshare now?

GNU Octave, as a superset of the MATLAB language, was (is) most capable of running existing MATLAB code. While Octave implemented some solvers better than MATLAB, the former just could not replicate a large enough portion of the latter's functionality that many scientists/engineers were unable to fully commit to it. I wonder whether runmat.org would run up against this same problem.

The other killer app of MATLAB is Simulink, which to my knowledge is not replicated in any other open source ecosystem.

Re: In Defense of Matlab Code

#78

Post by hatmatrix »

fph wrote: post #7
lemonwaterlime wrote: post #2

There's also Julia. Earlier in my career, I found that my employers would often not buy Matlab licenses, or would make everyone share even when it was a resource needed daily by everyone. Not having access to the closed-source, proprietary tool hurt my ability to be effective. So I started doing my "whiteboard coding" in Julia and still do.

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.

An understated advantage of Julia over MATLAB is the use of brackets over parentheses for array slicing, which improves readability even further.

The most cogent argument for the use of parentheses for array slicing (which derives from Fortran, another language that I love) is that it can be thought of as a lookup table, but in practice it's useful to immediately identify if you are calling a function or slicing an array.

Re: In Defense of Matlab Code

#79

Post by hatmatrix »

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…

It's one of those languages that outgrew its original purpose, as did Python IMHO. So non-matrix operations like string processing and manipulation of data structures like tables (surprisingly, graphs are not bad) become unwieldy in MATLAB - much like Python's syntax becomes unwieldy in array calculations, as illustrated in the original post.
Post reply on HN