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

71–80 of 100 posts

Re: GNU Octave 6.1.0

#71

Post by srtjstjsj »

tuix wrote: post #16

Currently you either have MATLAB+Toolboxes or Octave+Packages. I always wondered whether there could be a project to create open source toolboxes that would run in MATLAB. That means no effort is needed to maintain the core language features of MATLAB (of course you would need to buy the basic MATLAB licence without the Toolboxes) in that project and all the energy is spent on developing open-source toolbox replaceme…

The economics don't work well. Softest economy comes from scale, so the best bang for buck is to make free popular things, not to shave $50 off the edge case of your MATLAB outlay.

Re: GNU Octave 6.1.0

#72

Post by qppo »

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…

For me the issue is less performance and more correctness/completeness. Mathworks has teams of engineers working on their toolboxes, which helps a lot for users that need features and needs them to work correctly.

It's been some time since I had to use Octave because I didn't want to pay for a Matlab license, but I recall remez() didn't properly implement the Parks-McClellan algorithm and would return suboptimal results (which is a problem, when the algorithm is intended to find the optimal solution).

Also, Simulink.

Re: GNU Octave 6.1.0

#73

Post by srtjstjsj »

qayxc wrote: post #48
curt15 wrote: post #34

Could this project be threatened by Mathworks if SCOTUS rules that APIs themselves get copyright?

I don't think so. I imagine it would be very hard for Mathworks to claim copyright over mathematical functions and established terms such as "fft" or "rms". On top of that, Octave isn't even in competition with MATLAB. The much higher performance and capabilities offered by MATLAB that aren't available in Octave (like C++ export including support for GPU acceleration) along with professional support are enough to kee…

Changing names isn't a way around a copyright violation.

Re: GNU Octave 6.1.0

#74

Post by rwlincoln »

precsim wrote: post #64
rwlincoln wrote: post #62

Earlier quoted context omitted.

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…

The GNU Octave interpreter and its dependencies are all in the matpower.wasm file. 19Mb is still quite large for a website, but it is loaded asynchronously and WASM get compiled as it streams in. The interpreter runs in a WebWorker using a Promise based interface so the UI doesn't get held up. Many of the dependencies (e.g. FFTW, CHOLMOD, ARPACK, Qt, HDF5) are disabled as they are not needed to run MATPOWER. There was no particular reason for using v4.4.1. The core functionality of GNU Octave doesn't change much and that version was stable and sufficient for my needs.

Re: GNU Octave 6.1.0

#75

Post by patrec »

dragonwriter wrote: post #67
patrec wrote: post #65

Earlier quoted context omitted.

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.

What on earth are you talking about? If I add `def bar...` to a file foo.py in my PYTHONPATH, it does not suddenly become available in my interactive session, I need to import it first. Further if I change foo.py even importing it again in the repl (or jupyter notebook) will not have any effect. You will need to use one of several reload hacks which in practice won't work reliably for all sorts of reasons. In contrast, unless my memory severely fails me (and I don't think so, since I just checked against octave), in matlab if you edit a file in the path, it will be auto-imported every time you save it as soon as the repl is non-busy.

Have you actually used both matlab and python?

Re: GNU Octave 6.1.0

#76

Post by ptero »

dfrankow wrote: post #70
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…

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.

I often need to visualize data and unfortunately, plotting and working with many millions of points is a key capability. For example, we might have an expensive piece of hardware that we are using and need to understand if an issue we are seeing is a problem in our user software, a firmware we wrote to interface with it, or comes from the hardware itself.

Having technical representatives from each team (each sure that his team has nothing to do with it; can they please go back to their offices now) in a room looking at the same instrumentation data with ability to quickly dig into various features and subsets is a huge help for such problem isolation. At least in my experience it depends on fast interactive plotting and filtering of large datasets.

Re: GNU Octave 6.1.0

#77

Post by danmg »

3dsynd wrote: post #18

What value can Octave give me, relative to python?

You have some crusty MATLAB code that does an analysis exactly the way you need it. It was either written by someone who is long gone, or you don't have the resources to rewrite it in 202x's new computational language.

Re: GNU Octave 6.1.0

#78

Post by IshKebab »

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…

> 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 sufficiently cheap that I really would recommend getting that unless you absolutely can't afford it.

Re: GNU Octave 6.1.0

#79

Post by IshKebab »

dorfsmay wrote: post #46
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…

Is Julia not the new player in that game?

Julia's plotting is also unusable slow unfortunately.

Re: GNU Octave 6.1.0

#80

Post by enriquto »

3dsynd wrote: post #18

What value can Octave give me, relative to python?

> What value can Octave give me, relative to python?

For me the main thing is that math is "native", I don't need to import anything to start doing linear algebra. In python, doing math seems like an afterthought. For example, python offers you strings and dictionaries out of the box, but not ndarrays. In Octave, it is exactly the opposite, and it just feels right.

Post reply on HN