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

A new release for GNU Octave

lwn.net

Post reply on HN
Print view View original

91–99 of 99 posts

Re: A new release for GNU Octave

#91

Post by skissane »

tpoacher wrote: post #60
enriquto wrote: post #12

Earlier quoted context omitted.

I have always used Octave and never Matlab. The professor who introduced me to Octave some 15 years ago was quite the free software activist and did not even tell us that it was a clone. Today, I am a heavy user of Octave's linear algebra algorithms for large sparse matrices. I also use Python/numpy for other things, and sometimes for linear algebra too (due to the insistence of my coworkers), but it is much less ple…

I wouldn't call it a clone, anymore than I would call, say, Linux, a "clone" of Windows for needing to have a similar feature-set to appease newcomers. Much like linux vs windows, octave and matlab started life as completely different things, but octave being the 'underdog' and having a similar enough syntax necessarily tried to match matlab's syntax, to the extent that they pride on compatibility (and treat non-comp…

> I wouldn't call it a clone, anymore than I would call, say, Linux, a "clone" of Windows for needing to have a similar feature-set to appease newcomers. Much like linux vs windows, octave and matlab started life as completely different things, but octave being the 'underdog' and having a similar enough syntax necessarily tried to match matlab's syntax, to the extent that they pride on compatibility (and treat non-compatibility as 'bugs')

Nobody calls Linux a "clone" of Windows or vice versa, because even when they implement the same features, in the vast majority of cases the command syntax, APIs, etc, are radically different. There are a few commonalities, but when they exist, they are almost always because both have decided to implement some pre-existing standard. Even when Windows borrows features from Linux/Unix, it normally changes the API in incompatible ways – Windows 10 added pty support copied from Unix and Linux, but came up with an incompatible API to do it (CreatePseudoConsole)

It is the fact that Octave quite intentionally copied a lot of Matlab's syntax which leads it to being called a "clone". If they hadn't done that, nobody would apply that term.

> I think it's safe to say that matlab has 'borrowed' a lot of octave's nicer features over the years too (though obviously it's not something that can be publically admitted), like implicit broadcasting, command-line functions etc.

When Matlab "borrows" features from Octave, does it intentionally choose the same syntax, or does it implement the feature in an incompatible way? The former would constitute cloning, the later would not.

Re: A new release for GNU Octave

#93

Post by andi999 »

enriquto wrote: post #74
andi999 wrote: post #72

Earlier quoted context omitted.

Here is my story. We used Matlab, but then the polling of the license server got more and more aggressive(or we were unlucky). Just when you want to work on the 8h flight the thing popping up and saying 'need to connect to the internet' is not fun. Now we had a volume license(I think). And it needs server access every 10 times you run a script. Try making software which wants to use the Ethernetport with something el…

> Octave is slower than Matlab (at least last time, no loop acceleration), and no GUI library. So we went straight to python. But don't you find python slower? I prefer octave to python, in part, because the linear solvers are much faster (and the startup time, too).

To get fast you need to vectorize. I found that vectorizing algorithms in Matlab makes them unmaintainable (maybe I am not good at that). In python this is much smoother.

Re: A new release for GNU Octave

#94

Post by Der_Einzige »

heyitsme wrote: post #80
Der_Einzige wrote: post #53

Earlier quoted context omitted.

Matplotlib is terrible (once you get to the point that you need to do non trivial things with it), that's why you use the excellent plotting library for python called "Bokeh"

could you give an example of an "non-trivial" thing you're talking about (i.e a few lines of code)? And how you solve it with "Bokeh"? I agree that matplotlib's functional interface is somewhat messy, but that is somewhat historical, and stems from wanting to mimic how matlab works. I personally find matplotlib's OO interface both very powerful, and somewhat intuitive, once one gets a hang of it, hence I'm curious of…

See my other post in this comment chain. Matplotlib is not good with handling large (e.g. more than 100K) datapoints in 2D or 3D if you want interactivity or animations. Bokeh handles it like a champ!

Re: A new release for GNU Octave

#95

Post by BlueTemplar »

fafner wrote: post #79
BlueTemplar wrote: post #62

Earlier quoted context omitted.

As a student of Computational Physics, because we have more teachers using Octave than Python. However, its lack of support for Unicode variables and filenames is very frustrating in this day and age… (I understand that they are being stuck due to Matlab having poor support too.)

I believe Unicode support was improved in this (6.1) release

Yes, it's mentioned in the review, but there are no details given. I doubt that Octave suddenly started supporting either of those features.

Re: A new release for GNU Octave

#96

Post by enriquto »

andi999 wrote: post #93
enriquto wrote: post #74

Earlier quoted context omitted.

> Octave is slower than Matlab (at least last time, no loop acceleration), and no GUI library. So we went straight to python. But don't you find python slower? I prefer octave to python, in part, because the linear solvers are much faster (and the startup time, too).

To get fast you need to vectorize. I found that vectorizing algorithms in Matlab makes them unmaintainable (maybe I am not good at that). In python this is much smoother.

> I found that vectorizing algorithms in Matlab makes them unmaintainable. In python this is much smoother.

Are you using numpy? If so, can you give a concrete example?, in my case the opposite seems to be true. The numpy notation seems to be much clunkier.

Apart from that, this sentence:

> To get fast you need to vectorize.

describes a very sad tragedy of numerical computing. It makes no sense that in 2021 interpreters for scientific languages are not able to optimize loops. The so-called "vectorization" should be a non-issue in a modern interpreted language. The running time of calling "C=A*B" and that of the triple loop to fill the elements of the matrix C should be identical.

Re: A new release for GNU Octave

#97

Post by andi999 »

enriquto wrote: post #96
andi999 wrote: post #93

Earlier quoted context omitted.

To get fast you need to vectorize. I found that vectorizing algorithms in Matlab makes them unmaintainable (maybe I am not good at that). In python this is much smoother.

> I found that vectorizing algorithms in Matlab makes them unmaintainable. In python this is much smoother. Are you using numpy? If so, can you give a concrete example?, in my case the opposite seems to be true. The numpy notation seems to be much clunkier. Apart from that, this sentence: > To get fast you need to vectorize. describes a very sad tragedy of numerical computing. It makes no sense that in 2021 interpret…

I hope I remember these things correct. Let's assume you have two 3D arrays and you want to form the point wise product and sum over the middle index, you can probably write sum(a*b, 1). Anything more complicated there is numpy einsum (check it out) https://numpy.org/doc/stable/reference/generated/numpy.einsu... Letme know how these things can be nicely done in Matlab. One problem I had in Matlab is some vectorization requires to permute the indices, but this is expensive if your array is hundreds of megabyte.
Post reply on HN