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.
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)
Every parameter of the plot has reasonable defaults, and you can redefine all of them as you wish.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.
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.
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..?
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])from matplotlib import pyplot
pyplot.plot([0,1,2], [0,2,4])