Gnuplotlib: A gnuplot-based plotting backend for NumPy
github.com
github.com
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's where a lot of alternatives fall down. That and the multiple very mature backends and library integrations.
P.S. I also highly recommend using the object base API. There's a lot of learning material around the web that still uses the old MatLab inspired plotting api which has a plot of gotchas, the object based one is pretty clean.
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.
There is so much matplotlib and plotly code on the web, that nothing else comes close to the effortless plotting of matplotlib/plotly.
I almost never have to write the styling myself. LLMs understand matplotlibs complex, but well specified docs really really well.
This points to a larger trend. If you want your language or hard-to-learn tool to get adoption. Then you better have an LLM that does 90% of the work for newcomers.
It's the '*a language is only as good as its idee*' phenomenon that every Java user is surely aware of; but 2024 version.
Therefore, the title should be “gnuplot for numpy.”
It makes a whole lot of sense.
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.
I've done so in this case.
You gave to call fig.canvas.draw but it doesn't always work and sometimes plt.pause works but sometimes it only partially updates the display and you have to call it multiple times. (At least this in is my experience with TkAgg backend.)
Meanwhile you can't interact with it.
I would love a version of matplotlib which lives in a separate process and gets updated via nonblocking communication.
I'm a noob, it's honnest question.
Also, it's hard to beat gnuplot's speed refreshing a live scatter plot with many thousands of points using the x11 terminal.
And I usually keep computation and plotting separate. Computation produces data files, and a gnuplot script generates plots. This separation of computation and plotting allows updating charts later if needed, collected data can be reused in other plots, and additional data analysis can be performed and charts can be augmented.
So I personally don't see many advantages from integrating chart generation into computational pipeline itself (except for computation monitoring or maybe when user response is needed to direct computation). Because of that, libraries that encourage charts generation from a computed array instead of dumping that data into persisted files feels like an anti-pattern to me.
The graphs look as good to my eye as what I see in papers, but I have no idea what extra steps are needed to satisfy each journal's style guide.
Before Matplotlib, I created graphs in Excel.
A possible question is whether Matplotlib deserves the status of being the default for teaching scientific programming in Python, or if a different tool would make it easier for beginners.
from matplotlib import pyplot as plt
import pyplot
pyplot.plot(lambda x: math.sin(x))
pyplot.plot(x=[0,1,2],y=[0,2,4])from matplotlib import pyplot
pyplot.plot([0,1,2], [0,2,4])
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.
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.
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)
Yeah, and that's really not helpful for sharing code or doing exploratory charting. It's never, ever as simple as just "being done with it".
vega-lite-api is my charting library of choice these days. Much simpler than gnuplot, d3, matplotlib, etc.
x = np.arange(0, 10, 0.01)
pb.plot(x, np.sin(x)
pb.show()
what do you mean hard?
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.
Broadly, the problem is that its syntax was meant to reflect that of Matlab, which, I guess, makes it intuitive for Matlab users. For the rest of us, it's mostly unintuitive and inconsistent.
I would be genuinely interested what are the inconsistency from a Python-perspective.
I am former Matlab/Octave user. To me the julia interface of matplotlib is actually quite nice to use, but unfortunately the installation is a bit brittle.
Some settings only exposed to figure class but not the ax class. And when you are doing stuff towards ax class, you must write
ax.set_ylim(0,3)
instead of
ax.ylim(0,3)
Matplotlib.pyplot is known for its nonsensical api.
By the way, who came up with the idea that an axis object is a great handle to handle subplot settings..?
It looks like lets-plot does not implement the ggplot2 theme interface yet, unlike plotnine which is 99.99% compatible with ggplot2. On the other hand lets-plot also includes additional geospatial functionality on top of basic ggplot2 compatibility.
pl 'data.dat' u 1:3 w p pt 7 lc 3 tit 'Interesting measurements'
It's not nearly as maintainable as more-verbose and well-specified languages, but it's far more readable than regex :).
Edit to add: simply plotting a two-column data file in Gnuplot is as simple as:
pl 'data.dat'
Edit: you responded fast with your edit, but can you explain the full command -verbose? :)
plot 'data.dat' using 1:3 with points pointtype 7 linecolor 3 title 'Interesting measurements'By the estimation of one esteemed colleague "it obviously pays back the time investment in less than a couple of days". I agree.
(ggplot(mtcars, aes("wt", "mpg", color="factor(gear)"))
+ geom_point()
+ stat_smooth(method="lm")
+ facet_wrap("~gear"))
My problem with all the popular plotting libraries in python is they seem designed for researchers slapping together a paper and produce code that's awful to maintain.
This criticism doesn't do anything for me.
Is an alias for a 3 letter function name really going to improve readability / usability? It's the same API. Take it up with Hadley Wickham.
I think having one interface that is the same (ok, "mostly the same") for R and Python is a blessing for people who work with both. I don't graph with Python much, but every time I have to plot in Python I sigh and ask myself if it would be easier to just import the data into R.
In this case, absolutely. Plus it shows the attention to detail, or lack thereof, across the whole API.
- 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.
It's also quite nice to be able to use the same interface in both R and Python, although it is obvious that it was originally developed for R.
> _with is a curve option that indicates how this dataset should be plotted. It’s _with and not with because the latter is a built-in keyword in Python. [1]
- [1] https://github.com/dkogan/gnuplotlib/blob/master/guide/guide...
eg., pseudocode,
def plotLinear(data, options):
drawCanvas(options);
drawAxes(options);
drawGrid(options);
drawPoints(data);
drawLine(calcRegressionLine(data));
drawLabel(options);