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

61–70 of 100 posts

Re: GNU Octave 6.1.0

#61

Post by enriquto »

ptero wrote: post #56
dorfsmay wrote: post #46

Earlier quoted context omitted.

Is Julia not the new player in that game?

It probably is, but new vs old is not a big decision driver for me. The things that matter to me for scientific computing languages are visualization tools (most critical to me, by far), libraries for standard functionality like optimization and signal processing (not critical as I can use another language for back-end processing) and price. I will try Julia's visualization tools sometime, but if MATLAB is significan…

> Just a single user's data point, not claiming that this is a universal view.

Definitely not for me. As a matter of principle, I try to keep my computation and visualization tools strictly separate. Even, "artificially" separate, if you may. I would actually like octave more if it didn't provide a plot function. It would be closer to the spirit of the unix philosophy.

Re: GNU Octave 6.1.0

#62

Post by rwlincoln »

pojntfx wrote: post #55
rwlincoln wrote: post #42

I was able to compile GNU Octave 4.4.1 into Web Assembly for my MATPOWER PWA. When Mozilla was still at full force OctIodide might have been an interesting project for them. https://matpower.app https://github.com/iodide-project/iodide

That's an awesome project! Do you have some guidance on getting Octave to compile on WASM?

Satisfying the BLAS/LAPACK dependency was one of the biggest challenges. I ended up passing LAPACK 3.4.2 through f2c before compiling the result with emcc. PCRE and some SuiteSparse libraries were the only additional dependencies needed for my project and they compiled with Emscripten without too much difficulty. The rest was just hacking GNU Octave's Autotools build system, which gleans a lot of information from the system environment, into working with emconfigure and emmake. My changes to the GNU Octave source code are available here:

https://github.com/rwl/octave-4.4.1/tree/web-assembly

Re: GNU Octave 6.1.0

#63

Post by fnordfnordfnord »

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…

Like you, I haven't used either for serious work in many years but the last time I was doing serious work I found Python to be much faster. I discovered this by accident after porting one of my Matlab programs to Python and noticed an immediate 4x speed improvement. I worked with both for many more years afterward and in my experience Python was usually faster with a few exceptions.

That said, Matlab had great tech support and the sales rep was always super helpful. They were much nicer to work with than say National Instruments.

Re: GNU Octave 6.1.0

#64

Post by precsim »

rwlincoln wrote: post #62
pojntfx wrote: post #55

Earlier quoted context omitted.

That's an awesome project! Do you have some guidance on getting Octave to compile on WASM?

Satisfying the BLAS/LAPACK dependency was one of the biggest challenges. I ended up passing LAPACK 3.4.2 through f2c before compiling the result with emcc. PCRE and some SuiteSparse libraries were the only additional dependencies needed for my project and they compiled with Emscripten without too much difficulty. The rest was just hacking GNU Octave's Autotools build system, which gleans a lot of information from the…

This is very interesting and would never have guessed that it is possible. I would love to read a more detailed write up how all this works (is everything bundled to a large blob for the octave interpreter for example?). Also is the a specific reason you used v4.4.1? And playing with the PWA everything seems instant, but Octave is ~1Gb installed, wouldn't the Octave wasm have to be downloaded to the client (which it doesn't seem to do)?

Re: GNU Octave 6.1.0

#65

Post by patrec »

billfruit wrote: post #51
wallwart wrote: post #4

I've always preferred MATLAB to Python as the more engineer-friendly programming language. The interface was a plus as well. That being said, given the sheer amount of scientific libraries for Python and universities moving towards it as well, I'm wondering if the effort to maintain Octave is worth it. One use for it could definitely be running older MATLAB scripts that have deprecated language features. Those were a…

MATLAB seems ill condusive for structuring and organising code in a sane manner. It tends to give its users bad habits with respect to structuring code is what I observe. It seems to lack data structures that are quite pervasive in modern programming practise. Also python being a general purpose system brings its own benefits, one can easily hook up ones code to fetch or push data to databases and even easily scrape…

Matlab is much lower friction than python.

You write a function, using nice linear algebra syntax. Already python is worse: you do a bit of import boilerplate and write linear algebra in a gimped notation. You call the function. Not so in python, where you have to import it first. You change the function definition, next call will be redefined function. In python you can try to do an interactive reload via third party software but chances are it won't work right since Guido apparently never considered this something worth designing properly (apart from matlab lots of "real" programming languages are much better at this, including erlang, common lisp and smalltalk).

Your function runs too slow. You press a button and you see a color coded version of the code in your editor window and see instantly where the bottleneck is. In python you break out one of several crappy profilers. You want to save your results from your interactive exploration "save results.mat" -- done. In python there are various ways of saving stuff, which are either not general or slow or don't work between different versions.

I haven't used matlab in years, but as an interactive environment for linear algebra it blew python out of the water and likely still does, even if it has a number of big shortcomings as a general purpose programming language (and probably a worse selection of libraries in quite a few numerical domains these days as well). This is particularly true if the people using it are not trained programmers.

Re: GNU Octave 6.1.0

#66

Post by ptero »

enriquto wrote: post #61
ptero wrote: post #56

Earlier quoted context omitted.

It probably is, but new vs old is not a big decision driver for me. The things that matter to me for scientific computing languages are visualization tools (most critical to me, by far), libraries for standard functionality like optimization and signal processing (not critical as I can use another language for back-end processing) and price. I will try Julia's visualization tools sometime, but if MATLAB is significan…

> Just a single user's data point, not claiming that this is a universal view. Definitely not for me. As a matter of principle, I try to keep my computation and visualization tools strictly separate. Even, "artificially" separate, if you may. I would actually like octave more if it didn't provide a plot function. It would be closer to the spirit of the unix philosophy.

Your point is perfectly valid. I do separate my computation and visualization (sometimes both are MATLAB; just separate). For me the MATLAB is primarily an interactive visualization tool, although the main use case for most engineers I am sure is to use MATLAB for its scientific computation functionality.

Re: GNU Octave 6.1.0

#67

Post by dragonwriter »

patrec wrote: post #65
billfruit wrote: post #51

Earlier quoted context omitted.

MATLAB seems ill condusive for structuring and organising code in a sane manner. It tends to give its users bad habits with respect to structuring code is what I observe. It seems to lack data structures that are quite pervasive in modern programming practise. Also python being a general purpose system brings its own benefits, one can easily hook up ones code to fetch or push data to databases and even easily scrape…

Matlab is much lower friction than python. You write a function, using nice linear algebra syntax. Already python is worse: you do a bit of import boilerplate and write linear algebra in a gimped notation. You call the function. Not so in python, where you have to import it first. You change the function definition, next call will be redefined function. In python you can try to do an interactive reload via third part…

> You call the function. Not so in python, where you have to import it first.

Er, no you don't, if you are using it in the same notebook, module, or REPL session where you defined it. And if you aren't doing the equivalent in MATLAB, you also would have to load the definition.

Re: GNU Octave 6.1.0

#68

Post by srtjstjsj »

MaxBarraclough wrote: post #35
monsieurbanana wrote: post #33

Earlier quoted context omitted.

How about emacs homepage? It's been redesigned recently if I remember correctly. https://www.gnu.org/software/emacs/

Nice. My one complaint is that the text contrast seems a little lower than it could be. The text should be a true (0,0,0) black.

Only old people need full contrast. Low contrast text signifies hip youthfulness, which is important in any technology solutions :-/

Re: GNU Octave 6.1.0

#69

Post by srtjstjsj »

vonwoodson wrote: post #44
wallwart wrote: post #4

I've always preferred MATLAB to Python as the more engineer-friendly programming language. The interface was a plus as well. That being said, given the sheer amount of scientific libraries for Python and universities moving towards it as well, I'm wondering if the effort to maintain Octave is worth it. One use for it could definitely be running older MATLAB scripts that have deprecated language features. Those were a…

I spent the majority of my career porting MATLAB to C++. We charge about $70 an hour ($200 billable man-hour) to do it. It’s a slow and arduous process. Often times the features that are running in Matlab needs some C++ library that prevents the sort of speed increase that you hoped to gain out of the C++ port, so a C++ reimplementation of the toolbox needs to be developed anyway; this loosing the benefit of the “ver…

I saddens me a bit to see someone with the ability to do that work being paid less than a 1st-year FAANG engineer.

Unless it's freelance work you pick up in your excess time, or as a student job.

Re: GNU Octave 6.1.0

#70

Post by dfrankow »

ptero wrote: post #56
dorfsmay wrote: post #46

Earlier quoted context omitted.

Is Julia not the new player in that game?

It probably is, but new vs old is not a big decision driver for me. The things that matter to me for scientific computing languages are visualization tools (most critical to me, by far), libraries for standard functionality like optimization and signal processing (not critical as I can use another language for back-end processing) and price. I will try Julia's visualization tools sometime, but if MATLAB is significan…

ggplot?

If your benchmark is plotting 2 million points, it may also be slow. However, I find its ability to rapidly prototype tons of different visualizations useful. I try to avoid needing to plot 2 million points anyway.

Post reply on HN