I always find it easier to produce publication-quality figures using gnuplot (but not with its defaults settings, mind you) than with Matplotlib. Check out http://gnuplotting.org/
Also, it's hard to beat gnuplot's speed refreshing a live scatter plot with many thousands of points using the x11 terminal.
I'm using gnuplot for plotting too (the actual gnuplot application not a library that uses gnuplot as its backend).
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.
Matplotlib has been working fine for me. Some caveats. I'm a physicist working in industry, and don't publish in academic journals. But I do a huge amount of data visualization, for my own use, and to produce graphs for internal reports.
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.
Nothing, really. I have been using matplotlib for years and it's... fine.
The only problem I have is that is has number of minor annoyances that are never getting fixed, despite being well known and the project actively maintained.
From the top of my head: the Tk backed not supporting DPI scaling on GNU/Linux; the aspect="equal" not working on 3D plots; covered parts of 3D objects appearing in front of the objects covering them, twin axes not having the origin aligned, etc.
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.
People who are making plots in the terminal don't want to type out the fully qualified library name. Majority of plots are written and read only once during data exploration and analysis time.
rwxrwxrwx|2 years ago
Also, it's hard to beat gnuplot's speed refreshing a live scatter plot with many thousands of points using the x11 terminal.
a-nikolaev|2 years ago
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.
Silphendio|2 years ago
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.
coldtea|2 years ago
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.
greendayle|2 years ago
x = np.arange(0, 10, 0.01)
pb.plot(x, np.sin(x)
pb.show()
what do you mean hard?
analog31|2 years ago
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.
rnhmjoj|2 years ago
fransje26|2 years ago
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.
kwertzzz|2 years ago
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.
unknown|2 years ago
[deleted]
alanbernstein|2 years ago
dheera|2 years ago
krapht|2 years ago
stargazer-3|2 years ago
from matplotlib import pyplot
pyplot.plot([0,1,2], [0,2,4])
Izkata|2 years ago