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

GNU Octave: A high-level interactive language for numerical computations [pdf]

octave.org

Post reply on HN
Print view View original

61–70 of 70 posts

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#61

Post by kxyvr »

kiriakasis wrote: post #39
kxyvr wrote: post #4

Earlier quoted context omitted.

I work as an applied mathematician writing numerical codes and I prefer to prototype in MATLAB/Octave for a number of reasons: 1. I believe it to be far easier to debug an algorithm in MATLAB/Octave than Python. When I drop into the debugger, I can immediately check things like the eigenvalues of a matrix with a simple "eig(A)" or look at the sparsity visually with "spy(A)". Though this is possible in Python, I belie…

I only had short experiences with MATLAB/Octave as a student but found that writing MATLAB/Octave rather than MATLAB or Octave was tricky... (IIRC mostly with differently named library functions) Is this a nuisance also for you? I would be interest in how do you overcome this (asking for a friend working in image processing in MATLAB)

To me, it depends on how toolbox dependent your code is. Octave Forge has a lot of really nice libraries, but their interfaces tend to differ from MATLAB toolboxes, so getting codes to go back and forth can be a pain. In core MATLAB/Octave, most of the code is the same with some minor differences. For example, Octave doesn't care about wrapping a line with ..., but MATLAB does. Honestly, that's the most common issue that I have, but the MATLAB parser finds it and it doesn't normally take me more than a few minutes to fix things.

I recall there being some minor differences in how mex files are written, but I'm looking now and all the routines I typically use are mirrored between the two. I will say that I don't like building mex files using mex command inside of the interpreter. Personally, I find it easier just to use a build system like CMake. Mex files are just dynamically linked libraries that link either to libmx and libmex on the MATLAB side or liboctinterp on the Octave side. They look for name mexFunction on our end. As such, I have a flag in the build file to switch between MATLAB and Octave headers and libraries depending on what platform that I want to build for. Just be sure to separate out the binaries because those aren't really compatible between the two and the licensing between them is different as well.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#62

Post by cbkeller »

Q6T46nT668w6i3m wrote: post #48
4thaccount wrote: post #34

Earlier quoted context omitted.

Well written Julia should definitely be faster in most cases unless Matlab is using a specific well performing algorithm that Julia doesn't have built-in. With that being said, there are a lot of Julia posts on the subreddit or stack overflow that go like "Why is this Julia code 10x slower than my Python code"? One issue is that getting good performance out of Julia isn't always obvious without a pretty good understa…

They should be similar if they both rely on standard LLVM optimizations. I assume both have their own optimization passes on some mid-level IR but I personally don’t know whether one or the other has any particular language features that dramatically improve performance over the other. I’d like to hear more!

I assume they're referring to cases like this [1].

A few years ago I think there were some performance regressions in Julia relative to JIT'd Python (which, using LLVM like Julia, is way faster than normal Python). This seems to be mostly fixed now.

In the example above, the OP was getting 2ms in Numba vs 8ms in Julia three years ago, and recommendations from Julia folks were able to get the latter down to parity with an equivalent algorithm or 386us with an improved algorithm.

On my laptop today, I seem to get 2.0ms in Numba, 2.7ms with Julia 1.0, and 80us using the improved algorithm in Julia 1.0 (and, just to drive home the importance of compilation, 780ms in Python without Numba).

[1] https://old.reddit.com/r/Julia/comments/3x6tg9/why_is_this_l...

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#63

Post by 4thaccount »

kxyvr wrote: post #60
zozbot123 wrote: post #58

Earlier quoted context omitted.

> Matlab is usually only ~$20 for an engineering student Guess what, apparently the first hit is not always free. There are people posting in this thread who have to pay as much as 20k per year for a fully licensed Matlab.

There was a little bit more information about that above. I'm a professional and my initial cost was around $2k and my yearly cost is around $400. I don't have to pay the yearly, but I like the updates and I like getting a response when something breaks and I'm on a tight deadline. I can't stress enough that what you buy with MATLAB is license coverage. Octave and Julia hook into many of the exact same libraries, but…

That's a pretty good and useful point. I don't sell software (just use what I write), so I'm not worried about encrypted binaries at the moment. If I was actually selling software though I probably would be. The GPL has always been a double-edged sword to me. Sure it is nice and free as in beer and freedom, but it can also essentially mean that it is a complete no go.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#64

Post by kryptk »

sampo wrote: post #43
sitkack wrote: post #2

What benefit does Octave have over the Python ecosystem? Esp as a clone of proprietary software? The only thing I can see is as a way of running Matlab codes in clusters on cloud w/o having to also run the license servers.

Matlab: exp(-i*pi*[0 0.5 1]) Python: import cmath import numpy as np np.exp(-1j*cmath.pi*np.array([0, 0.5, 1])) Note that you can't use math.exp for complex numbers, and neither math.exp nor cmath.exp works for arrays, you need the separate np.exp. Also, while np.exp actually works on lists, the multiplication doesn't, so you need to keep in mind which variables are python lists (that you mostly cannot do arithmetic…

None of what you said is wrong, but:

1) there is no need to import anything but numpy to get at pi or e (see constant section of numpy docs).

2) if you wrap all your things you expect to behave like vectors/matrices with np.array() and only use np methods to operate on them you will suffer from shape mismatches instead of TypeErrors, a slightly better fate.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#65

Post by byt143 »

wxnx wrote: post #53
IshKebab wrote: post #24

Earlier quoted context omitted.

What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python. Additionally I've not found a plotting solution that is as robust and fast as MATLAB. MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.

R is nice for stats stuff, even if performance can be iffy for certain tasks. The existing libraries for basic ML tasks are largely fantastic. The syntax rubs many people (including me) the wrong way. But I don't like the paradigm for basic ML tasks in scikit-learn (python) much better. Anything involving matrix computation is great to do in python because of existing libraries (numpy). I think most people who are ac…

> I think it has potential to be the language of choice for non-neural-network stats/ML (that's python for the foreseeable future).

I think it will overtake python for NNet stuff also: https://julialang.org/blog/2018/12/ml-language-compiler

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#66

Post by bassman9000 »

sitkack wrote: post #2

What benefit does Octave have over the Python ecosystem? Esp as a clone of proprietary software? The only thing I can see is as a way of running Matlab codes in clusters on cloud w/o having to also run the license servers.

For simple stuff, just open the GUI+REPL, and start plotting in Matlab. Great for quick documentation graphics.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#67

Post by fiveFeet »

std_throwawayay wrote: post #30

I have used Matlab and GNU/Octave in parallel for some years half a decade ago. Octave can do most things that I needed but was slower to run for many things. With Octave you didn't run into licensing problems as those floating licenses had their limits and sometimes I needed to run quite a few instances in parallel. Now I use Python exclusively. The language is so much better and more sane and almost any library is…

^ This! Very similar experience here! Moved to Python from Matlab and never looked back.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#68

Post by IshKebab »

cbkeller wrote: post #25
IshKebab wrote: post #24

Earlier quoted context omitted.

What do you use instead though? Octave is very slow, Julia is even slower and Numpy has an annoyingly verbose syntax because it has to be valid Python. Additionally I've not found a plotting solution that is as robust and fast as MATLAB. MATLAB seems to me to be one of those commercial programs that has no good FOSS alternatives. Maybe it's just too niche, like CAD and EDA.

> Julia is even slower Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..

It may execute faster when it finally gets around to it. But just loading the plotting library (Gadfly) takes over 10 seconds!

https://github.com/JuliaLang/julia/issues/4373

Starting all of Matlab never took that long.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#69

Post by ChrisRackauckas »

IshKebab wrote: post #68
cbkeller wrote: post #25

Earlier quoted context omitted.

> Julia is even slower Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..

It may execute faster when it finally gets around to it. But just loading the plotting library (Gadfly) takes over 10 seconds! https://github.com/JuliaLang/julia/issues/4373 Starting all of Matlab never took that long.

I don't know what version of MATLAB you're using :P. They definitely have their logo screen open for a minute or two before the program shows up. That's quite a long load time. They just made it pretty.

Re: GNU Octave: A high-level interactive language for numerical computations [pdf]

#70

Post by byt143 »

IshKebab wrote: post #68
cbkeller wrote: post #25

Earlier quoted context omitted.

> Julia is even slower Huh? This has definitely not been my experience -- most of the things I've ported over seem to run about twice as fast in Julia as in the original vectorized Matlab (and probably more like 10x faster than naive non-vectorized Matlab)..

It may execute faster when it finally gets around to it. But just loading the plotting library (Gadfly) takes over 10 seconds! https://github.com/JuliaLang/julia/issues/4373 Starting all of Matlab never took that long.

Have you tried under julia 1.1? Latency issues much better, and will only improve.
Post reply on HN