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

171–174 of 174 posts

Re: In Defense of Matlab Code

#171

Post by wiz21c »

FacelessJim wrote: post #144
wiz21c wrote: post #139

Earlier quoted context omitted.

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)

Yeah, it didn’t have the explosive success that rust had. Most probably due to a mixture of factors, like the niche/academic background and not being really a language to look at if you didn’t do numerc computing (at the beginning) and therefore out of the mouth of many developers on the internet. And also some aspects of the language being a bit undercooked. But, there’s a but, it is nonetheless growing, as you prob…

more or less my experience too. But I'd like it to succeed. Fortran is now the COBOL of science. I'll continue to follow it closely.

Re: In Defense of Matlab Code

#172

Post by kelipso »

quietbritishjim wrote: post #148
D-Machine wrote: post #117

Earlier quoted context omitted.

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

> It simply isn't possible to do serious math with vectors that are ambiguously column vs. row ... if you have gone through proper math texts (There is unhelpful subtext here that I can't possibly have done serious math, but putting that aside...) On the contrary, most actual linear algebra is easier when you have real 1D arrays. Compare an inner product form in Matlab: x' * A * y vs numpy: x @ A @ y OK, that saving…

x @ A @ y is supposed to be a dot product and you are saying this is better notation?? Row and column vectors have actual meaning. Sorry but I am not reading the rest of whatever you wrote after that. Not the GP but you should just consider the unhelpful subtext to be true.

Re: In Defense of Matlab Code

#173

Post by jakobnissen »

wolvesechoes wrote: post #127
jakobnissen wrote: post #120

Earlier quoted context omitted.

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…

> Pythonistas think it's a great argument in favor of Python that all performance sensitive Python libraries must be rewritten in another language. It is, because usually someone already did it for them.

That's fair - if you work in a domain where you can solve your problems by calling into existing C libraries from Python, then Python's speed is indeed fine.

Re: In Defense of Matlab Code

#174

Post by markkitti »

fluidcruft wrote: post #149
FacelessJim wrote: post #147

Earlier quoted context omitted.

Checkout PythonCall.jl and juliacall (on the python side). Not to mention that now you can literally write python wrappers of Julia compiled libraries like you would c++ ones.

I will, thanks. > you can literally write python wrappers of Julia compiled libraries like you would c++ ones Yes, please. What do I google? Why can't julia compile down to a module easily? No offense but once you learn to mentally translate between whiteboard math and numpy... it's really not that hard. And if you were used to Matlab before Mathworks added a jit you were doing the same translation to vectored operat…

>> you can literally write python wrappers of Julia compiled libraries like you would c++ ones. > Yes, please. What do I google? Why can't julia compile down to a module easily?

Try JuliaC for compiling shared libraries if that is what you mean by a "module": https://github.com/JuliaLang/JuliaC.jl

That said Julia's original design focused on just-in-time compilation rather than ahead-of-time compilation, so the AOT process is still rough.

> I don't understand why there's so much friction between julia and python. You should be able to trivially throw a numpy array at julia and get a result back.

You can throw a numpy array at Julia and get a result back. See https://juliapy.github.io/PythonCall.jl/stable/juliacall/

Post reply on HN