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

GNU Octave 6.1.0

gnu.org

Post reply on HN
Print view View original

91–100 of 100 posts

Re: GNU Octave 6.1.0

#91

Post by MaxBarraclough »

dehrmann wrote: post #85
Zhyl wrote: post #25

Earlier quoted context omitted.

You say that, but I feel like it's a bit of a case of 'dress for the job you want'. Having a modern-ish looking site just gives off some signals like 'this is maintained', 'this has been deemed to still have utility in 2020' and 'the developer has some awareness of current UX'. It doesn't need to be flashy. Just a nice font, a header, centre justification, some spacing, a paragraph explaining what the thing is, a nic…

I had this thought recently--is there a class of website where being being un stylish and looking like it came out of an earlier era of web design gives the site more credibility?

Sure, sites like Pinboard, SourceHut, and of course HackerNews, that appeal to the bloat-averse traditionalists who believe web pages should be lightweight.

It's not about aiming for an ugly UI, it's about getting out of the way and presenting a clean, simple, fast, functional page.

The designation brutalist web design has gained some traction. (I would have linked to an article on this, but ironically the page I found was offensively spam-ridden.)

Re: GNU Octave 6.1.0

#92

Post by qubitcoder »

MaxBarraclough wrote: post #14

I know it's not really the point here, but it's nice to see a GNU project with a decent home-page. It's clear, presentable, and modern. (And of course it's not a JavaScript horror-show, but we'd never see that from a GNU project.)

The GNU Emacs website is similarly well done [0].

https://www.gnu.org/software/emacs/

Re: GNU Octave 6.1.0

#93

Post by stjohnswarts »

oytis wrote: post #6
tutfbhuf wrote: post #2

Ask HN: Can GNU Octave be used as full MATLAB replacement?

For me Simulink has always been the biggest missing part. Also RTL (or other code, e.g. for DSP chips) synthesis for Octave is pretty non-existent AFAIK.

When I was doing FPGA work Simulink was very handy for plugging together quick signal processing flows. I kind of miss it, but I've moved on to strictly c/c++ embedded work

Re: GNU Octave 6.1.0

#94

Post by tomsmeding »

ptero wrote: post #39

I wish Octave the best of luck, but it faces an uphill battle against MATLAB (established engineering projects) and Python (new starts). The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB. A major use case for me is visualizing large data sets. I can generate data using any backend (Python, C++, MATLAB, etc.) and want the ability to plot it, zoom in/out to a rectangle, filter to a…

How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2 points). Its concept of "scatter plot" is: 1920x1080 image, draw a non-antialiased (i.e. ugly) filled blue circle of radius 4 at each point, where the unit square is stretched over the entire image.

Doing this (C++, CPU) takes ~0.21 seconds for 2 million points, and ~2.06 seconds for 20 million points. The result is a solid blue rectangle, but that's beside the point.

Doing the same on a trivial GPU implementation using CUDA, where I cheated by not even using atomic operations (so this only works because the dots are solid), takes ~0.23 seconds for 2 million points and ~2.3 seconds for 20 million points. Apparently the (my? (GTX 1050 mobile)) GPU doesn't help here.

For comparison, with matplotlib (`plt.scatter(x, y); plt.show()`): for 2 million points, plt.scatter() takes ~10 seconds, and plt.show() takes about 3 seconds fill first image. Zooms/resizes etc. seem to be the same time, or if less points show, proportional to the number of visible points.

So unsurprisingly my cheap C++ code is faster than matplotlib (it doesn't even anti-alias), but is it faster than Matlab? I have neither Octave nor Matlab, perhaps you can compare with matplotlib?

EDIT: my code here https://gist.github.com/tomsmeding/1631090df10ab5ac98403304e...

Re: GNU Octave 6.1.0

#95

Post by gnufx »

Not to do down Octave, but if you want a free alternative to MATLAB, Scilab might be worth checking out too, particularly for an alternative to Simulink, as I understand it. It has a different emphasis, like not aiming at compatibility the way Octave does.

It grieves me to see how much money squander on MATLAB (and they're apparently not allowed to compare notes, which says something). The ones I'm familiar with pay around (or more than) enough to fund a full-time support post, so there could instead be a significantly-sized sustainable research support team working in that area, just in the UK.

Re: GNU Octave 6.1.0

#96

Post by ptero »

tomsmeding wrote: post #94
ptero wrote: post #39

I wish Octave the best of luck, but it faces an uphill battle against MATLAB (established engineering projects) and Python (new starts). The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB. A major use case for me is visualizing large data sets. I can generate data using any backend (Python, C++, MATLAB, etc.) and want the ability to plot it, zoom in/out to a rectangle, filter to a…

How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2 points). Its concept of "scatter plot" is: 1920x1080 image, draw a non-antialiased (i.e. ugly) filled blue circle of radius 4 at each point, where the unit square is stretched over the entire image. Doing this (C++, CPU) takes ~0.21 seconds for 2 million point…

Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certainly fast enough to render dots on the screen as fast as interactive processing needs.

What I suspect is taking place with Octave/Python/Julia-based tools is the additional information that needs to be handled for each plot. You need to draw axes and ticks, keep tracks of which points are displayed and obscured at at the current axes limits and update all that information every time any of those things change (reset/move/zoom, etc.). It is certainly possible to make abstraction layers that are convenient for software engineers but would not scale well with respect to the number of points that need to be plotted. Or, instead of carefully tracking each state change one could regenerate a large portion of it to make it simpler (and slower). Just a guess though.

Re: GNU Octave 6.1.0

#97

Post by wrp »

gnufx wrote: post #95

Not to do down Octave, but if you want a free alternative to MATLAB, Scilab might be worth checking out too, particularly for an alternative to Simulink, as I understand it. It has a different emphasis, like not aiming at compatibility the way Octave does. It grieves me to see how much money squander on MATLAB (and they're apparently not allowed to compare notes, which says something). The ones I'm familiar with pay…

I have used both Octave and Scilab as a substitute for MATLAB. Scilab is a much more polished system, but it has multiple gotchas if you are moving back and forth between it and MATLAB. Octave aims for full MATLAB compatibility, but I found the system pretty rough all around.

Re: GNU Octave 6.1.0

#98

Post by diydsp »

gnufx wrote: post #95

Not to do down Octave, but if you want a free alternative to MATLAB, Scilab might be worth checking out too, particularly for an alternative to Simulink, as I understand it. It has a different emphasis, like not aiming at compatibility the way Octave does. It grieves me to see how much money squander on MATLAB (and they're apparently not allowed to compare notes, which says something). The ones I'm familiar with pay…

Re simulink: I have experimented with OpenModelica a little bit for making simulations! didn't get too deep, but was impressed with my initial foray.

Re: GNU Octave 6.1.0

#99

Post by tomsmeding »

ptero wrote: post #96
tomsmeding wrote: post #94

Earlier quoted context omitted.

How fast does it have to be? I was curious and implemented a trivial loop in C++ that draws "scatter plot" on your benchmark (scatter plot with lots of [0,1]^2 points). Its concept of "scatter plot" is: 1920x1080 image, draw a non-antialiased (i.e. ugly) filled blue circle of radius 4 at each point, where the unit square is stretched over the entire image. Doing this (C++, CPU) takes ~0.21 seconds for 2 million point…

Thank you for the data point, but I do not think the issue is with rendering of the dots on screen (although I am not sure). In fact, I have done some real-time, frame-by-frame video processing using OpenCV and had no issue processing 1920x1080 images in real-time at 25fps (40ms per frame), including some simple edge detection, segmentation and rendering on screen using my office workstation. Modern hardware is certa…

I do think it's plotting the points that is hard: note that what I'm measuring is not rendering the image on the screen, but creating the image of the dots in the first place. Creating the image is O(number of dots) work; displaying the image is O(number of pixels) work and GPU-accelerated and peanuts.

I think this because in the end, after all the axis settings and such have been determined (and drawing the axes themselves is surely not the bottleneck), all that remains is just drawing the dots in the rectangular area set out for it. My benchmark does only that part, and as I said, I'm about 50x faster than matplotlib. (C++ and not Python, so I'm not picking on matplotlib, just observing.)

But anyway, if this issue is to be solved it is to be done by contributing to Octave/matplotlib etc, not by throwing around proof-of-concepts on HN. :)

Re: GNU Octave 6.1.0

#100

Post by IshKebab »

ptero wrote: post #81
IshKebab wrote: post #78

Earlier quoted context omitted.

> The biggest issue with Octave for me is the slowness of its plotting compared to MATLAB I was going to say exactly the same thing. The language implementation is mostly fine-ish. But plotting (which is like half the point of MATLAB) is unusable slow. It's not just Octave though. All of Julia's plotting libraries are similarly slow. MATLAB still has a monopoly on fast scientific plotting. Matlab's hobby license is s…

This (individual non-commercial license) is my current approach, too. I wonder though, why do we have such a lack of fast scientific plotting, as you wrote? Is it due to the fact that few people really care or is there some inherent set of hard problems that Mathworks figured out how to handle?

I have no idea to be honest. I don't think there is much that is really hard about it. It's probably a ton of work because to be really useful you have to support a ton of options (like rotated labels, log axes, dashed lines, stepped lines, gaps in lines, etc. etc.). It's a nearly endless list and I guess to do that and to make it not slow is just loooads of work.

Probably in Octave's case it is just really ancient code that uses X11 or something. They probably need to rewrite it to use Skia or similar, or even OpenGL. Maybe something like MathGL: http://mathgl.sourceforge.net/doc_en/plot-sample.html#plot-s...

I've never tried that though.

Post reply on HN