[HN Gopher] A new release for GNU Octave
___________________________________________________________________
A new release for GNU Octave
Author : signa11
Score : 185 points
Date : 2021-01-03 08:26 UTC (14 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| elisaado wrote:
| Recently I've been using SageMath, it's python based.
| castratikron wrote:
| I'm hoping the next generation will move off of TI-8x calculators
| and into things like Octave for grade school use.
|
| There was a point in my education where I had mastered my trusty
| TI-83; I knew the purpose of every single function and how to use
| them. But then, I started running into problems in the real world
| that required more than 32 KB of memory to solve. When I moved to
| a laptop I had to relearn all of that knowledge again. Haven't
| touched my TI-83 since.
|
| It would be nice if the tools we learned how to use in school
| could also be useful in solving our problems after we graduate!
| fafner wrote:
| I wish they'd rather use python or Julia. GNU Octave is great.
| But as a clone of Matlab it's constraint by compatibility and
| doomed to always be second* and at worst an enabler for Matlab.
| I'd rather break the dominance that Matlab has in many fields
| and replace it with free software.
|
| * There are a few aspects where it is better. For example I
| believe the variable editor introduced one or two releases ago
| is nicer as it allows inline evaluation.
| marmaduke wrote:
| > rather use python or Julia .. break the dominance that
| Matlab has in many fields and replace it with free software
|
| I still think Octave has a niche to fill for students and HPC
| where software engineering (package management, compilation
| etc) is of insufficient concern.
| KingMachiavelli wrote:
| At least in the US, high school education still and probably
| will use TI calculators for the foreseeable future. They are a
| long existing standard and very practical for that environment.
| However, most AP classes do allow the use of the TI-Nspire
| which is a much more capable platform than the TI-8x series.
| And even in that series, the TI-84 and variants are much more
| popular now.
|
| At the college level, at least for engineering programs, at my
| school there was a pretty big emphasis on doing a lot by hand
| besides trivial stuff like addition and multiplication. The
| extent that we would utilize calculators seemed very minimal.
| Most of the degree programs including teaching students one or
| more of Mathematica, matlab, octave, and R. But I would say it
| sounds like the depth you had for the TI-83 doesn't really
| exist in the modern education, rather it is a more broad use of
| multiple platforms.
| nikanj wrote:
| Not sure what kind of lobbying & campaign contributions have
| built the TI stronghold on the education market, but highschool
| kids today seem to use pretty much the same TI-85 that I had in
| the 1990s, except with a more colorful shell.
| thefunnyman wrote:
| Was in high school in the 2010s and I had to buy a TI-84.
| They have a version with more storage and a color display but
| it's still that same calculator all these years later.
| rich_sasha wrote:
| I'm curious, are there any Octave users on HN? What are your use
| cases, in particular different to just an open-source Matlab-like
| clone? Why Octave not Python?
|
| I'm curious, not saying either option is bad.
| bayindirh wrote:
| As a MATLAB license holder, I'm currently migrating some MATLAB
| code to be compatible with both.
|
| My license doesn't allow multiple computers, so MATLAB is
| living on my laptop. I'd rather run longer computations on my
| desktop system, which can handle these loads for a long period
| time without getting stressed thermally.
|
| My use case is to run ground-truth code designed by my
| professor and cross-check the results generated by my
| scientific software. These MATLAB/Octave generated values are
| also incorporated to sanity check and CI pipelines to test
| developed software's sanity and computational integrity.
| Frost1x wrote:
| This is the main use case where I've used octave: working
| with someone of a group who has developed fairly involved
| Matlab codebase and we need to make it more scalable in some
| way, either for long running computation, reducing license
| costs, perform distributed memory work, or enable more robust
| parametric space exploration.
|
| The Achilles heel here is that in Matlab, there's quite often
| a licensed toolbox dependency which makes portability more
| challenging. Every now and again I've seen pure Matlab code
| and the Octave transition is smooth. Sometimes there are so
| many toolbox dependencies that it just isn't even worth
| trying.
| bayindirh wrote:
| The luck in my case is, since we're testing either
| algorithms for formulations, most (if not all) code is
| written in pure MATLAB and has no toolbox dependency.
|
| However, we're living in a matrix world. MATLAB is slow and
| Octave is even slower while working with matrices. I have
| no idea how to fix that part.
| Jtsummers wrote:
| > MATLAB is slow and Octave is even slower while working
| with matrices.
|
| I'm curious what you mean with this. Matlab was always
| fast with matrices (but my experience is now from 2
| decades ago). The thing that was slow was loops. That is:
| for i = 1:100 c(i) = a(i) + b(i); end
|
| would always be slower than this: c = a
| .+ b;
|
| The trick in my work was to always find matrix/vector
| operations that were equivalent to my desired loop and
| conditional structures. I could improve execution by 100x
| or more for many programs doing this.
| marmaduke wrote:
| I didn't see it anywhere, so: Octave start up speed is
| magnificent. If you have a larger shell script and just need to
| grab some eigenvalues, Octave can be as fast to startup, do its
| work and exit, as awk or grep would be for text manipulation.
|
| MATLAB takes a while to start, Julia and Python need to spend a
| good amount of time importing/compiling.
| andi999 wrote:
| 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 else, it is
| just annoying. So you pay a lot of money and get annoyed...
|
| Octave is slower than Matlab (at least last time, no loop
| acceleration), and no GUI library. So we went straight to
| python.
| enriquto wrote:
| > 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).
| smallpipe wrote:
| I've used it to copy a matlab library into hobby software,
| whilst being able to debug it to compare.
|
| Details in my previous comment:
| https://news.ycombinator.com/item?id=25441585
| gautamdivgi wrote:
| I actually went the other way from Octave to scipy, numpy and
| matplotlib. This really long ago though - around 2007. As a
| programmer moving into quants needing to process huge amounts
| of data python/matplotlib seemed a much better fit for me. It
| also enabled me to run multiprocess number crunching on my
| 8-core desktop at home. Octave would be able to use just 1
| core, I could code the python scripts to use all 8.
|
| Octave was really good to prototype and enabled me to get
| somethings done really quick. But once I got to know the python
| libraries better it just seemed easier. I could do all my data
| processing and quants in a single language.
|
| I'm sure much has changed and was actually quite sad when the
| original author of Octave (John Eaton) mentioned in 2017 that
| he was unable to maintain it.
|
| I've lost touch on Octave over the years and genuinely pleased
| to see that it is still being actively maintained. I think its
| time for me to see what I've missed in the past 13 years.
| sudosysgen wrote:
| I use it to do general linear algebra scripts and as a linalg
| calculator. The language is imo much nicer at this than python,
| and it also starts up way faster.
|
| Also, symbolic calculation is a lot less cumbersome than in
| python!
| kergonath wrote:
| I use Matlab-likes (actually Scilab rather than Octave) for one
| offs and interactive use. That's usually playing with a
| dataset, test some analysis techniques, quick regressions,
| solving linear equations systems, this sort of things. I hate
| having to set up the whole machinery when doing this in Python.
| Also, the general-purpose nature of Python gets in the way,
| whereas the Matlab-like syntax is very focused and much less
| cumbersome. This does not matter much in a script, but is a
| pain for interactive use. On the other hand, Matlab is terrible
| to write scripts, with its inconsistencies and its almost-
| Fortran-but-weirder syntax.
|
| Once the pipeline is set, Python is for scripts that need to be
| run more than about a dozen times, or need to be run on several
| datasets, or for things that need to be reproduced exactly
| (like stuff that goes into a paper). I also use it to prepare
| datasets from large numbers of calculations where the useful
| results need to be gathered from dozens/hundreds of files in a
| more or less complex file structure, often on different
| computers, with the occasional pass with some post-processing
| tools.
|
| I really dislike Matplotlib, so rendering is done in something
| else, usually gnuplot.
|
| That's for my stuff (mostly atomic-scale modelling and quantum
| chemistry in materials science), it might be different for
| other use cases...
| herogreen wrote:
| I really like matplotlib: while it is not intuitive and the
| documentation is sometimes lacking, there are a lot of
| examples online and stackoverflow answers all my questions.
|
| That said I may use matplotlib much less than you do (I used
| it a lot when I was a student, now maybe 6 times a year).
| Der_Einzige wrote:
| 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"
| kergonath wrote:
| Never really looked into it; I'll have a closer look. What
| do you think is its strengths?
| Der_Einzige wrote:
| For me? I care mainly about 2D and 3D scatter plots of
| large datasets. The GPU acceleration and automatic
| subsampling means that animated or interactive scatter
| plots of large amounts of data (for me it's language
| vectors) is super easy and fast rather than slow and
| crappy with matplotlib...
|
| (I think matplotlib has an openGL backend that slightly
| improves but doesn't fix the issues with matplotlibs
| handling of large datasets)
| pletnes wrote:
| Bokeh is also made to create embeddable, interactive
| plots for html/js. You can create quite sophisticated
| graphics with it from the backend alone. (We use it for
| web apps at $WORK)
| heyitsme wrote:
| 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 specific cases where it fails
| for you.
| enriquto wrote:
| > I really dislike Matplotlib, so rendering is done in
| something else, usually gnuplot.
|
| This! My biggest gripe against Python numerical stuff was
| matplotlib, until I realized that it is an entirely optional
| component of the stack, and you can plot by other, much saner
| means.
| mkl wrote:
| Yes, there are many good alternatives. Seaborn, Plotly, and
| many more. I still use Matplotlib for most things (with the
| OO API), as I can control its fine details and it's more
| versatile. For non-graph visual things that I could use
| Matplotlib for, I've been generating SVGs and displaying
| them directly in Jupyter notebooks (with Cairo is one
| option, but just directly is pretty easy too).
| leephillips wrote:
| You may have other reasons for preferring Matplotlib, but
| I don't think anything allows more control over fine
| details or is more versitile than gnuplot.
| billfruit wrote:
| GNU plot syntax somehow feels less discoverable, less
| intuitive, one constantly needs to be looking at the docs
| while doing it, was my experience.
| leephillips wrote:
| I can't really disagree. It takes a while to come to
| grips with its concepts and language for settings. But
| basic plotting is concise and intuitive.
|
| I was mainly commenting on its configurability. Gnuplot
| lets you (once you figure out how) control everything;
| for example, the exact shape of the arrowheads in a
| vector plot.
|
| (The name is "gnuplot"; it's not a GNU project.)
| mkl wrote:
| I've never had much use for Gnuplot. It can do lots of
| things, but in my experience, it's been easier to get
| what I want in other tools. Most of my plots are created
| in Python programs, Latex documents, or interactive web
| pages, where I use tools focused on that purpose and
| embed the code where it fits. For most of my one-off
| explorations there are better tools too.
|
| If I'm using Matplotlib, I'm almost always plotting
| things calculated in Python, so all my data and variables
| are right there ready to go. I think the fine details are
| controllable in more programmatic ways than Gnuplot. I
| use other Python libraries when they're a better fit.
|
| If I'm doing one-off throwaway plots, there are better
| and easier tools than Gnuplot: Desmos, GeoGebra.
|
| If I'm making interactive demos, there are better tools
| than Gnuplot: Desmos, GeoGebra, JSXGraph, Jupyter.
|
| If I'm plotting a function for a high-quality PDF
| document, TikZ gives me more control than Gnuplot, and
| makes it easy to make many plots with consistent (and
| changeable) style, though being a Latex-based tool it has
| limitations to go with its power. TikZ is great for
| diagrams too. Asymptote is more powerful than TikZ in
| some ways for this kind of thing, but often harder to
| use.
| enriquto wrote:
| Sure, but none of these beats gnuplot's uber-elegant
| "plot sin(x)" syntax :)
| mkl wrote:
| Sympy can do that: plot(sin(x))
|
| This of course works with other symbolic manipulation:
| plot(sin(x).diff()) plot(sin(x).subs(x, x**2))
| enriquto wrote:
| Can you show the complete code for these snippets to
| work? I tried import sympy
| sympy.plot(sympy.sin(x))
|
| and it says "NameError: name 'x' is not defined"
| mkl wrote:
| You need to tell Python that you want a symbolic variable
| named x: from sympy import * x =
| symbols('x') plot(sin(x))
|
| symbols is sympy.symbols.
| enriquto wrote:
| It's not particularly elegant, is it?
|
| You just want to plot the sine function, but first you
| have to import libraries, declare symbols (with a scary
| correspondence between strings and variable names), and
| finally plot the damn function.
| nxpnsv wrote:
| One import statement is too much?
| mkl wrote:
| I literally always have a Jupyter QtConsole open with one
| tab having Sympy loaded, and every single letter variable
| defined as a symbolic variable, and another tab with
| numpy; this is my constant daily-use calculator. In that
| context, it really is just "plot(sin(x))". It's not
| really anything more than having a terminal open with
| Gnuplot running, and no less elegant.
|
| Edit: plus, if I'm plotting with Sympy it's almost
| certainly something I've calculated symbolically with
| Sympy, so everything is defined and ready, and it's much
| more elegant than switching to a separate program. For a
| one-off "what does function look like?" question, both
| these tools are far too clunky, and I'd use Desmos or
| GeoGebra.
| abdullahkhalids wrote:
| If people have to reduce to this hack, why doesn't the
| language just declare every character string a symbolic
| variable by default, like Mathematica?
| mkl wrote:
| Because the vast majority of Python programs aren't doing
| symbolic maths with Sympy. It's not a hack, and it's
| pretty trivial. I type "a," and press up, and run the
| line from my command history with all the letters in it.
| Sympy also has a submodule named abc you can import
| variables from, but I like defining them as real number
| variables so I don't get complex answers when they don't
| make sense.
|
| Sympy is just a Python library, and one of the types it
| defines is symbolic maths variables, so you define Python
| variables just like with any other library, and then use
| them.
| enriquto wrote:
| > Because the vast majority of Python programs aren't
| doing symbolic maths with Sympy.
|
| And this, my friends, is why mathematicians will never
| feel at home using Python+libraries. Instead of having a
| programming environment ideally suited to the needs of
| math, you need to fit your math to the Procrustean bed of
| Python syntax.
| abdullahkhalids wrote:
| That is what I wanted to say. The Python scientific
| ecosystem seems like it is written by programmers for
| scientists, while Matlab/Mathematica seem like they are
| written by scientists for scientists.
| williamstein wrote:
| SageMath solves these problems.
| abdullahkhalids wrote:
| It does not. I tried to replicate some symbolic
| computation code I wrote during my PhD in Mathematica in
| SageMath, and I just failed to get anywhere despite weeks
| of trying. I don't think I don't understand SageMath
| enough.
| tomrod wrote:
| Exactly. Grandparent commenter is complaining about
| resolved issues that the community worked out years ago.
| tomrod wrote:
| Eh, it's fine even despite your hyperbole. Applied
| mathematicians such as myself often use python without
| complaint. Setting up sympy takes no effort. Plus,
| #python on freenode.
| kergonath wrote:
| Yeah, Matplotlib is capable, but it's heavy and verbose.
| It's fine as an API, but the syntax gets in the way very
| quickly.
|
| My use case is not a scratch pad with one plotting
| window; it's dozens of windows with regressions and
| stuff. Each window is a completely different context;
| some of them are short lived and some of them are used
| for weeks. Using as many notebooks is very impractical.
| For example, seeing where one parameter is going in one
| calculations is trivial and quicker than starting a
| notebook and setting it up. Works transparently over ssh,
| too.
|
| I am more or less fluent in Matplotlib, because I work
| with people who use it and I need to understand whatever
| the students are doing (and some of them use Python and
| some use R, which is a whole other discussion). I just
| dislike it and don't use it much for my things.
| Ultimately, gnuplot's syntax for regression and complex
| plots is much more concise.
|
| I any case I think it's good intellectual hygiene to use
| several tools regularly, lest you end up stuck in a way
| of thinking, so I encourage students to try others. It's
| also good to have discussions about these things that
| don't end up in holy wars; we need to be curious.
| WoodenChair wrote:
| > I really dislike Matplotlib, so rendering is done in
| something else, usually gnuplot.
|
| I'm glad I'm not alone. I was starting to feel crazy--how can
| something with this bad an API (Matplotlib) be this popular
| in the Python ecosystem which is known for its lack of
| verbosity and clarity? How can it be integrated with every
| other package instead of some sane alternative?
|
| I tried Seaborn (a wrapper effectively), and it is way better
| for doing basic plots. But as soon as you get beyond that
| you're back in arcane Matplotlib territory. The best thing I
| could have done would have been to ignore its integrations
| and start with a better plotting API to begin with. The
| little bit of extra integration effort would have been worth
| avoiding Matplotlib. And there are several alternatives in
| the Python landscape.
|
| No offense to the authors--it's clear they've done a lot of
| great work. But I think they got stuck with a bad API that
| they started with and it became so common-place that they
| were forced to continually be backwards compatible with
| something that really needed an overhaul.
| joe_biden123 wrote:
| seaborn is nice because it let's you do plots with one line
| that would take a page of code in basic matplotlib, but if
| you need to change one specific thing it might become
| really hard.
|
| I honestly moved on to gui based plotting programs like
| grace or veusz, there's just a button for the things you
| want to do
| tripa wrote:
| I drop to octave any time I need to do some one-off matrix
| computation. Also as an interface to GLPK.
| mkl wrote:
| I'll say one option is bad :-)
|
| I don't use Octave, but I have a little in the past, and I have
| to teach students to use Matlab (2021 should be the last year
| of that before we switch to Python though), and I've done a lot
| of numerical and other programming in Python and Matlab, in
| each for ~20 years.
|
| In my opinion Matlab is a terribly designed language that has
| haphazardly grown features by accretion. Anything other than
| matrices and vectors is far more difficult than it needs to be.
| Therefore I consider Octave a bit of a lost cause; I think
| aiming for compatibility with terrible won't lead anywhere
| good.
|
| Actually Octave has one useful feature Matlab is missing,
| operators +=, -=, etc., so perfect compatibility is not exactly
| the goal.
|
| It seems to me the only reason to use Octave is if you happen
| to have a large legacy Matlab code base that doesn't depend on
| any of Matlab's proprietary toolboxes (unlikely, as those
| toolboxes are one of the main reasons people use Matlab).
|
| I believe Python is superior to Matlab/Octave in almost every
| way. I think Matlab/Octave has two or three very small
| advantages over Python, and one larger but very niche one:
|
| 1) Matlab/Octave's matrix literal syntax is nicer and less
| verbose ([1 2; 3 4] vs. np.array([[1, 2], [3, 4]])). Irrelevant
| in most cases, as most substantive programs will have few
| literals in them. Note that those missing commas are a frequent
| source of bugs, too, e.g. [1 -2; 1 - 2] is an error, so really
| the Matlab/Octave is better written as [1, 2; 3, 4].
|
| 2) Because Matlab/Octave is primarily for numerical
| calculations, you don't need to import libraries to get
| started. Not a big deal as I always have a Jupyter QtConsole
| running with Python, Numpy and Sympy ready to use.
|
| 3) Basic 3D plotting in Matlab is still a little easier (Python
| is better for complex 3D plotting though). Not sure what
| Octave's story is for 3D plots.
|
| 4) The aforementioned proprietary Matlab toolboxes, if you
| happen to be working in one of the narrow niches they're good
| for. Python has similar large library advantages in other (and
| more) areas. Octave has some equivalent open source library
| bindings, but that's the biggest incompatibility with Matlab.
|
| 20 years ago Matlab was pretty good, but it's barely changed
| since then, and Python has long overtaken it in most areas.
| Octave seems to have caught up with Matlab on the GUI front
| (but Jupyter Notebooks are much nicer for many things (Octave
| can do Jupyter too), and Python has a selection of mostly
| equivalent IDEs, e.g. Spyder). Python, being a general purpose
| programming language, can do all the non-maths things
| surrounding the maths much easier. Data input/output, data
| processing, string processing, network access, etc., as well as
| UI things like Jupyter Notebooks. In my opinion Python's also
| better at quite a lot of maths stuff, like large integers,
| arbitrary precision, symbolic algebra, higher dimensional
| arrays, or dataframes with Pandas. I also much prefer 0-based
| indexing and half-open ranges.
|
| Matlab's licensing is quite problematic. Licenses for
| business/research use are incredibly expensive, and licenses
| for student use are relatively cheap. I consider it unethical
| to teach students to use a proprietary language that will cost
| their future employers thousands, but that's been Matlab's
| sales strategy for decades. Switching to Octave is an option
| for teaching and some business/research use, but switching to
| Python, with its much bigger ecosystem, seems more sensible to
| me (unless you have a big existing Matlab code base).
| rcxdude wrote:
| I agree wholeheatedly. Python is everything matlab the
| language could hope to be and more, if you just want to
| crunch matrices python beats matlab as it's own game (just
| the broadcasting features in numpy alone are an amazing step
| up from matlab's approach, let alone trying to ingest data
| which isn't a csv). But, some of those toolboxes are pretty
| damn good and don't have an equivilent in python. For
| example, if you're doing almost anything with control theory
| then there's some pretty killer toolboxes that don't have any
| real competition, especially in the open-source space
| (there's some basic stuff but it's not particularly usable).
| pvitz wrote:
| I have never understood why MATLAB hasn't introduced proper
| broadcasting like APL and its successors. My problem with
| Numpy is its awkward notation/syntax when compared to
| Matlab/APL.
| tpoacher wrote:
| Matlab has had broadcasting since 2016 (and obviously
| octave since forever)
| pvitz wrote:
| That is true, but "proper" broadcasting should include
| some way to manipulate it like a rank conjunction.
| bori5 wrote:
| " 20 years ago Matlab was pretty good, but it's barely
| changed since the " How do you define "barely" looking at
| just changes from 2015 to 2020 in just core MATLAB shows at
| least the following changes.
|
| https://www.mathworks.com/help/matlab/release-
| notes.html?cat...
| tpoacher wrote:
| It's important to be aware this says more about you and your
| personal preferences (and possibly experience and skill in
| either language) than about octave and its overall value-
| proposition as a project though.
|
| If I'm allowed to offer a (non-opinionated) counterpoint, I
| have almost the opposite experience and opinions to you (both
| in the positives and negatives).
|
| Background: I have been working daily with python for the
| last 3 years in a scientific field. Before this, I worked
| daily with octave for about 3 years in a similar field. I'm
| equally happy and skilled in both languages.
|
| So, to counter: point 1: I mostly agree, though I think the
| 'frequent source of bugs' point is slightly dramatic. If
| anything, to me it feels like the numpy system is much more
| conducive to bugs (e.g. given all the acrobatics one needs to
| do to ensure compatible ranks).
|
| point 2: You absolutely do need to import libraries in
| octave. And that is generally a positive thing for a number
| of reasons, not too dissimilar to python. However unlike
| python, the octave team maintains relatively strict control
| and quality-processes for 'official' and 'endorsed (third
| party)' packages. This has an advantage over python where for
| each popular package there are 100 clones and variants and
| poor or unfinished packages, sometimes even phishing
| packages.
|
| As for 'packages' in matlab, it's true you don't need to
| 'import' toolboxes, but this is only because of matlab's
| business model which sells them as add-ons. You can think of
| 'enable in licence' as an import of sorts if you'd like.
|
| point 3: Octave derives its plotting syntax from matlab, and
| for the most part it's very intuitive. I always felt
| matplotlib is a poor attempt at replicating that syntax, but
| thankfully there are alternatives.
|
| point 4: It's true that octave's biggest compatibility
| problem with matlab is in the 'toolboxes vs equivalent
| package' case. Which is partly why octave has been providing
| bindings to equivalent python packages as a workaround (same
| as Julia). One of the more successful examples is octave's
| reimplementation of python's sympy package, to create a
| symbolic package using matlab's api and simplicity of syntax,
| but calling python's sympy under the hood.
|
| As for the "python has more stuff", this is purely the
| networking effect. And while obvioulsly the networking effect
| is not a trivial issue for any language, as an open source
| project it is always a matter of time, which is not something
| that can be said for something like matlab. And I'm sure that
| octave's rising popularity in recent years through its
| promotion in things like Andrew Ng's introductory course to
| machine learning, can only lead to an increased engagement
| with the language, and we can expect lots of good packages to
| crop up as a result.
|
| point 5 (not labelled as such). I don't think the "python >
| matlab/octave" mantra is necessarily true. It's just personal
| opinion + engagement. It is certainly true that python has
| more users, but there are many reasons for that which cannot
| be reduced to a simple "python > matlab/octave". As for
| jupyter notebooks, I really dislike them and much prefer
| matlab/octave's 'publish' for producing straightforward html
| reports. But, again, that's just personal preference. Also, I
| much prefer 1-bassed indexing and closed ranges, as I find
| them much less prone to bugs.
|
| I agree about the prohibitive nature of Matlab's licence, but
| I do not necessarily agree that the "natural" choice is
| therefore python. Surely the decision is more multifactorial
| than that. After all, if it's ecosystem you're after, why not
| julia? or c++? or java? In my view, octave is a reasonable
| contender regardless of an existing matlab codebase. It is a
| friendly language, with a big open-source community,
| excellent math and graphing facilities, and can easily
| interface with other languages if you really need that extra
| pizzaz on occasion, without the overhead that comes from
| needing to have your whole project based on those languages.
| ai_gandalf wrote:
| I was introduced to octave through Andrew Ng's Machine Learning
| course, its good..
| [deleted]
| BlueTemplar wrote:
| 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.)
| fafner wrote:
| I believe Unicode support was improved in this (6.1) release
| enriquto wrote:
| 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 pleasurable
| and quite annoying. Also, the linear solvers in scipy are sub-
| par compared to the state of the art solvers in Octave. Once,
| we found a well-conditioned 6x6 system that linalg.solve failed
| to solve!
|
| As an aside, I have never used Octave for plotting, and I hate
| the gui interface; my use case is 100% non-interactive, using
| scripts.
| tpoacher wrote:
| 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'), but extend the matlab language to
| include other features.
|
| Now that both projects are mature, 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.
|
| Obviously, neither matlab nor octave are strict subsets of
| each other. Also, I get the impression that matlab has
| started taking octave's compatibility very seriously in
| recent years, and has taken non-trivial steps to break it
| (annoying, but totally fair, in my view), which octave has
| resisted for the sake of backwards compatibility. Ironically
| this often makes octave a more reliable base for runnin older
| matlab scripts, than matlab itself. (e.g. in the same way
| that Wine is more reliable for running Win98 applications
| than Windows 10)
| yummypaint wrote:
| Using Octave over matlab is preferable for me for the same
| reasons many people use GIMP over photoshop. I use octave for
| things that are reasonably self-contained, like the
| metaphorical editing of a single image. I like Python over
| octave for the kinds of uses that might cause someone to use
| python over GIMP for image processing, to extend the metaphor.
| paijiut wrote:
| I use it often. Even after 20 years of using
| numeric/numarray/numpy, I still feel more productive in Octave
| and Matlab. Mostly time series analysis, signal processing,
| image analysis. Occasional modeling and simulation work. I
| think for me it's that octave does it's job well and doesn't
| try to do other things. Python grates on me occasionally since
| it's libraries seem to lack focus and try to be too much for
| too broad of an audience. I like focused, simple tools. I do
| use Python, but not as my sole tool. I don't understand he
| mindset that one tool/language should do everything. Easier for
| me to learn many languages than one language and have to learn
| many independently designed libraries.
| billfruit wrote:
| Matlab never feels a particularly elegant system to me, and
| most Matlab codebases I have seen are huge messes, with not
| much structuring and organization. In that respect I prefer
| python, that it naturally seems to lead to saner manner of
| organizing code, and also being very helpful in
| massaging/parsing/reformatting data into forms more amenable
| to processing.
| marmaduke wrote:
| > Matlab codebases I have seen are huge messes
|
| I can confirm this, but, Conway's Law suggest that this
| reflects more the user group that the language. Matlab
| provides all the typical suspects for structuring codebases
| (packages, classes, functions, globals, etc) but look what
| users do with it. This suggests simply that research groups
| " communication structure"s are huge messes.
| _0ffh wrote:
| I wonder how much of this is due to the availability of the
| dot-operator syntax beside the extensive libraries and the
| easy extensibility (just create a new function in the Matlab
| search path and Bob's your uncle - no further installation or
| registration rituals needed).
| IshKebab wrote:
| MATLAB/Octave's main advantage over Python is that the syntax
| for manipulating matrices is way way way nicer. They also have
| a _lot_ of toolboxes and maths related functions that would
| really take a long time to find /implement in Python.
|
| MATLAB had another significant advantage over Python. Its
| plotting support is really really really good. Given how much
| time scientists spend making graphs it's hard to understate how
| important that is, or how much better MATLAB is at plotting
| than Python or Octave (or Julia).
| rcxdude wrote:
| In my experience matplotlib has surpassed MATLAB's plotting
| functions for most use cases. It's just so much more
| powerful.
| jb1991 wrote:
| > how much better MATLAB is at plotting than Python or Octave
| (or Julia).
|
| To make sure I'm understanding you correctly, you're saying
| Matlab is much better at plotting than Octave? I've only ever
| used the latter, so I guess that would be one reason to
| consider switching to the former.
| _0ffh wrote:
| Last time I tried a few years ago, Octave couldn't hold a
| candle to Matlab's plotting functions. It's a different
| league.
| rightbyte wrote:
| Octave's plots are missing some property editor and GUI
| tools which can be quite annoying. Like the brush or
| regression tool.
| tpoacher wrote:
| Interesting. My experience has been the exact opposite.
| The quality of matlab's plots paled compared to that of
| Octave's.
| _0ffh wrote:
| Didn't really notice any major difference in quality... I
| was talking ease-of-use and richness of options.
|
| What quality differences do you refer to?
| mkl wrote:
| I would actually say Python's matrix manipulation syntax is
| better, but Matlab's matrix literal syntax is much nicer and
| more minimal.
|
| Having made hundreds/thousands of plots in each, I think
| Matplotlib's plotting is a bit better than Matlab's,
| especially for complex plots where you need control and have
| subfigures, etc. Matlab's 3D plots are better than
| Matplotlib's (which are fake-3D), but for sophisticated 3D
| visualisation Python has powerful options like VTK that
| Matlab can't really match.
| PoachedSausage wrote:
| I use for it for the various RF/EE/Controls related matrix
| stuff, as others have said it is often quicker to use to do
| some sanity checks even though at work we have actual
| MATLAB/CST Studio etc.
| xvilka wrote:
| I would say "Why Octave not Julia?" since Julia is specifically
| designed for the scientific notations and speed, unlike Python.
| rich_sasha wrote:
| Good point, Julia is the Matlab of 21st century. Pythonista
| here, so Julia didn't come to mind first.
| leephillips wrote:
| I have my own answer at the end of the article. It is: use
| Julia if you're serious; but Octave will serve you well if
| you're already used to MATLAB or have MATLAB scripts and just
| want to do some numerical work.
| thatsadude wrote:
| Signal processing, 15 years using Matlab/Octave and 10 years
| using Python. It's easier to prototyping signal processing
| algorithms in Matlab/Octave. Some important functions in Scipy
| perform much worse than Matlab/Octave.
| rightbyte wrote:
| I use Octave alot for engineering calculations. Writing simple
| global namespace scripts with "hardcoded" values.
| abdullahkhalids wrote:
| I use Octave to quickly plot graphs or do quick non-trivial
| calculations during my lectures.
|
| Better than python because I don't have to import libraries.
| Haemm0r wrote:
| I use it from time to time. Octave performs very well to the
| point, where you have several encapsulated for-loops, where
| Matlab is several times faster in my experience.
| pletnes wrote:
| In several cases over the years, I've inherited matlab code and
| tried to run it on octave. Never worked, once. There were
| always just one small missing syntax, function, edge case of
| handling filenames...
|
| Once I inherited code written for octave. Did its job, worked
| like a charm, mostly. The CLI interface was clunky compared to
| typical shell tools so I had to do some shell wrappers and
| incantations to automate what I wanted. I don't know if this is
| due to the author or to octave but I suspect its focus is on
| interactive use to the detriment of developing programs.
|
| I keep a jupyterlab docker container running at all times on my
| win10 laptop, with windows-home mounted. Instantly available
| notebooks from my browser - works like a charm for interactive
| use.
|
| I much prefer python since it lets you move continuously from
| one-off hack in a notebook cell to a web scale application,
| parses any weird file, serves web content in 3 lines, etc.
| tpoacher wrote:
| I did all my work and wrote my entire biomedical engineering
| (specifically medical image analysis) thesis on octave.
|
| In the beginning I had started with matlab because my lab
| mostly used matlab functions. Obviously it's not that I
| couldn't finish my work on matlab, but I found octave nicer to
| use, better publication-quality graphs, very friendly open-
| source community, submitted bugs typically fixed within a
| couple of days (which was not the case when I submitted bugs in
| matlab, of which I had reported plenty, particularly when it
| came to misbehaving graphics), interesting outlooks from
| studying its source code, ability to keep or distribute my code
| in the absence of a prohibitive matlab licence, etc.
|
| It is probably true that it is not necessarily as quick as
| matlab or julia these days, however there is a big red flag
| when one looks at "benchmarks" online, which is typically that
| these are used in such contrived ways that a proper octave user
| would probably not consider as good octave code. (I remember
| this was also true of julia's benchmarks against python for
| instance).
|
| Octave in fact is very powerful. Not to mention that to the
| serious user, much of its power comes from its incredibly
| powerful interface to its vast library of open-source
| c++-implemented functions.
|
| As for the why octave and not python (or any other X) question
| ... honestly, I don't know. E.g. why Linux and not Windows?
| Honestly, both are fine. But, without having an explicit list
| of arguments, I just find linux is more enjoyable and gets out
| of my way, whereas on windows I find myself having to do extra
| steps and double-check things at every turn. Well, somehow, I
| have the same vibe when working on octave vs python or julia.
| But that's not to say I don't enjoy those other languages too.
| To me it just feels Octave is just ... nicer and gets out of
| your way somehow. It's definitely my language of choice for
| quickly trying ideas out.
| probably_wrong wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=25440787
| ibraheemmmoosa wrote:
| I always founding importing libraries to be fun.
| tails4e wrote:
| Matlab licensing is prohibitive for everyone in a team to have
| one and WAN licences are 4x the cost of a seat, so we tend to
| have code capable of running in both octave and matlab in
| general. The model is all users can use octave for lower level /
| common code components and it works finw, and then the system
| level guys who really require matlab for its toolboxes can also
| use them and that common code also. If it was not for the
| advanced matlab toolboxes (and some key engineers who know only
| matlab) we'd probably have moved to python or Julia.l to get away
| from this two tier use model
___________________________________________________________________
(page generated 2021-01-03 23:01 UTC)