Live data from Hacker News

Gnuplotlib: A gnuplot-based plotting backend for NumPy

github.com

41–50 of 69 posts

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#41
post #40

Earlier quoted context omitted.

Matplotlib isn't very friendly to casual users. For even the simplest possible plot, I have to create a subplot and axis. Sometimes I'd like to just plot a function. I don't want to initialize arrays for that. It's easy to forget that I have to `import matplotlib.pyplot` I don't need to plot things often, but whenever I use matplotlib, I always have to spend a few minutes to look up how to use it.

> For even the simplest possible plot, I have to create a subplot and axis. So? Can't that be abstracted away once in a custom lib, of the 3-4 plots you use 99% of the time, and be done with it? In which case, you just need to pass in your data and labels, in a specific format, and that's it.

> So? Can't that be abstracted away once in a custom lib, of the 3-4 plots you use 99% of the time, and be done with it?

This does not beat gnuplot's simplicity where you don't even need to define that.

The following line is a complete gnuplot program to plot the sine function:

    plot sin(x)
Every parameter of the plot has reasonable defaults, and you can redefine all of them as you wish.

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#42

I might have missed the memo where Gnuplot has a better api than matplot ;) Seriously though, there have been many attempts to make a "better matplotlib" and yet it's still going strong - mostly because when you really get into scientific plotting and need print quality plots or embed plots in an GUI with very specific parameters it's hard to beat. Sometimes you just need to place a label in a specific spot and that'…

I think matplotlib's main strength is its breadth and power. It really lets you do exactly what you want if you spend enough time fiddling and digging through the documentation.

All this versatility comes at the expense of ease of use. It could certainly do a better job of making the simple common use cases more straightforward.

gnuplot arguably has similar power and versatility and it does make the simple stuff easier.

One thing that matplotlib is IMO bad at is interactive plots. They are very slow, and the controls are not intuitive. 99% of the time you just want to zoom and pan and those should be default actions.

gnuplotlib looks interesting and I will have a look, but these days most of the plots I do are in jupyter notebooks and I really want inline interactive plots so I don't think I will use it much. FWIW, what I use currently is plotly - the interactivity is very good (way better than matplotlib's) and plotly.express is very easy to use for the simple use cases.

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#44
post #24
post #3

What's wrong with matplotlib? I might be living under a rock...

from matplotlib import pyplot as plt WTF? Broken from right there. What's a plt? "o" key broken? Why didn't they just call it pyplot? Why not just import pyplot pyplot.plot(lambda x: math.sin(x)) pyplot.plot(x=[0,1,2],y=[0,2,4])

The library is not forcing you to use plt as a shorthand. Nothing is stopping you from calling

from matplotlib import pyplot

pyplot.plot([0,1,2], [0,2,4])

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#46

Earlier quoted context omitted.

Why?

HN rules say: “… please use the original title, unless it is misleading or linkbait; don't editorialize.” Therefore, the title should be “gnuplot for numpy.”

Right.

Note that there may be times when titles may be substituted, usually for reasons of length, de-clickbating or de-sensationalising, etc. In which case the preferred option is to omit nonessential words or find an alternative, clearer, phrase within the article text itself.

But editorialising, even with relatively innocuous phrases such as "non-painful" is strongly frowned upon.

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#47
post #3

What's wrong with matplotlib? I might be living under a rock...

Matplotlib isn't very friendly to casual users. For even the simplest possible plot, I have to create a subplot and axis. Sometimes I'd like to just plot a function. I don't want to initialize arrays for that. It's easy to forget that I have to `import matplotlib.pyplot` I don't need to plot things often, but whenever I use matplotlib, I always have to spend a few minutes to look up how to use it.

import pylab as pb

x = np.arange(0, 10, 0.01)

pb.plot(x, np.sin(x)

pb.show()

what do you mean hard?

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#48
I'd imagine an issue with most plotting APIs is that they're declarative, and specified in terms of a semi-mathematical domain -- rather than imperative and specified as graphics operations. Since they're graphics libraries, that would make their operation more obvious.

eg., pseudocode,

    def plotLinear(data, options):
        drawCanvas(options);
        drawAxes(options);
        drawGrid(options);
        drawPoints(data);
        drawLine(calcRegressionLine(data));
        drawLabel(options);

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#49

Earlier quoted context omitted.

Matplotlib isn't very friendly to casual users. For even the simplest possible plot, I have to create a subplot and axis. Sometimes I'd like to just plot a function. I don't want to initialize arrays for that. It's easy to forget that I have to `import matplotlib.pyplot` I don't need to plot things often, but whenever I use matplotlib, I always have to spend a few minutes to look up how to use it.

import pylab as pb x = np.arange(0, 10, 0.01) pb.plot(x, np.sin(x) pb.show() what do you mean hard?

This is a minor source of confusion. Pylab and Pyplot are packages within Matplotlib. They are what most casual users experience when they say that they're using Matplotlib. I use them, they're convenient.

A minor headache is when you have to break out of Pyplot to use some of the more detailed behaviors of Matplotlib, and now you're interacting with both Pyplot and the lower level calls. For instance, plt.title('foo') and gca().set_title('foo') do the same thing.

If you're a fluent programmer, you fly past those seeming inconsistencies with barely any notice. Explaining them to a novice programmer is harder.

Re: Gnuplotlib: A gnuplot-based plotting backend for NumPy

#50
post #16
post #13

By far and away the best python plotting library is plotnine, a python clone of ggplot maintained by Hassan Kibirige from Uganda. By the estimation of one esteemed colleague "it obviously pays back the time investment in less than a couple of days". I agree.

I see the potential long term but that api is unintuitive at best. It almost seems obstructively terse. (ggplot(mtcars, aes("wt", "mpg", color="factor(gear)")) + geom_point() + stat_smooth(method="lm") + facet_wrap("~gear")) From https://github.com/has2k1/plotnine , their front page examples. I get that it's ripping off the ggplot api, but why would they not alias "aes" to something more meaningful? It stands for "ae…

As who hadn't seriously used any plotting library, some of my questions:

- Why isn't the first term `ggplot(mtcars, "wt", "mpg", color="factor(gear)")` instead? It seems that the second argument always has to be a `plotnine.mapping.aes(...)` call or a saved `aes` value. It is not really hard to distinguish `ggplot(data, saved_aes)` from `ggplot(data, "x-col", "y-col", ...)`. The only issue might be the third `environment` argument, but that can go elsewhere (see below).

- What's up with that operator overloading? Is `+=` even supported? It seems that the original R version had the same syntax, but Python's statement-based syntax makes it annoying to use. Maybe any "additions" should have been moved into `ggplot` arguments by default: `ggplot(mtcars, "wt", "mpg", geom_point(), stat_smooth(...), facet_wrap(...), color="...")`.

- Many "addable" values have common repeating prefixes (`geom_` etc). Doesn't sound like a good API design at all, especially in Python. Probably there should be a `geom` module and so on that are exposed via `from plotnine import *` instead, so that `geom.point()` would work for example.

- Formulae as strings are fine to have, but it somehow has multiple "stages" where they can be evaluated (`after_stat` etc). Such feature would be necessary from time to time, but the concept itself doesn't seem to be not well polished.

Post reply on HN