Before I got accustomed to gnuplot, I was most familiar with d3. I spent a lot of time prototyping different viz strategies for myself in d3. All I can say is, I was blind and now I see.
If you get a rush from piping massive csv files into sed/awk/grep/tr/cut, then into wc/sqlite3/[etc], and are at all interested in plotting visuals of the results for yourself, please do yourself a favor and spend 30 minutes riding the learning curve of this wonderful program. IME, the docs are wonderful and kind to beginners who aren't afraid to cmd+f for the bits they're interested in.
After a couple hours of fiddling, you'll find getting a first stab at a graph faster in gnuplot than in excel. Then, you'll wonder about all that time you could have been saving your whole life. Like any other cli tool, its language takes a bit of grokking, but you can institutionalize your knowledge in scripts and carry them with you the rest of your life. Seriously, try it out.
It depends on your use case. An obvious one is that gnuplot doesn’t require a web browser and a JavaScript VM, but I acknowledge this is irrelevant to some people.
gnuplot integrates seamlessly with a shell, so you can do all of your data transformation in awk/sed, and pipe the results into gnuplot. For d3, you’d need to load the data file, plot it, and then face the temptation of tweaking in JS vs tweaking the source data.
The first iteration of “I have a csv file” to “I have an interpretable graph” is very quick with gnuplot, which helps with prototyping and identifying systematic features of the data. You can squeeze d3 to get this, but you’d need to whip out a lot of boilerplate to get there. There are a bunch of frameworks built on d3 that promise this sort of experience, but if you want to end up with fine-grained control of the viz, you’ll need to drop down into d3 eventually.
You don’t have to know anything about HTML, the DOM or CSS to make a decent graph in gnuplot. Of course, if you’re skilled at these, you can make very nice interactive graphs in d3. Tangentially, I had a viz professor who would give any one who used interactivity to encode a dimension of information an immediate bias of -20%, because interactivity is more often a limiting element rather than a feature. :)
That being said if I wanted to build something productively interactive, I’d still reach for d3 over gnuplot.
Curious to hear others thoughts on your question, too!
When I did my master thesis we had to use servers we were not allowed to install most things on. But awk and gnuplot was there. All we needed for some great results. Thought of it as a hack in the beginning but in the end it became our whole pipeline.
Gnuplot was my first experience dealing with an open source project when I was starting my career. I went to their IRC channel and asked something related to the GNU project. I was immediately scolded: "Gnuplot is not a GNU project!!" :D
During my teenage years when I first started C++ (thank you Accelerated C++), I went to the ##c++ channel on Freenode and was immediately flamed for my "weird" nick, to the point that the people didn't bother to answer my question but instead went after me personally, just because I had picked a nick based on leet speak. I won't deny that it left a very bad impression on me about the open source community, especially as someone who was new to it.
I have only recently learned this and I too was surprised it's not a GNU project, and even more so it's not GPL-compatible.
The license it's essentially a BSD with the (absurd) restriction that you can't distribute the "complete modified source code", whatever that means, but only patches. I wonder what's the motivation.
For us, gnuplot and xmgrace were two of the most important command line tools during physics education, esp. in computational physics. Often piping freshly simulated data right into one of both for quick visualization.
I still use gnuplot for publication-quality graphs, when I can’t be arsed to use R.
It’s also still very useful to generate on-the-fly plots to help sifting through large numbers of datasets.
The last steps of my simulations is usually to generate a graph showing critical parameters to make sure it makes sense at a glance. Much easier than eyeballing number tables. Gnuplot is perfect for this: it is very fast and lightweight.
Gnuplot is really an awesome project. Though I don't use it all that much anymore, it will always hold a special place in my computing heart. In an undergrad physics lab it was my first experience with launching a program from a shell-- and that sure sent me in the right direction. Thanks to all who have contributed to the project.
Nice! I like it when you can plug such programs in a pipeline.
Recently found out that you can use png:- as source or destination in any imagemagick command, to pipe images around! I find it really useful in combination with xclip, with -t to set the mime type. You can paste the result almost anywhere!
From using gnuplot of a few versions ago for tasks involving rather many plot generation, I felt that the gnuplot syntax and commands are rather unintutive and hard to remember, perhaps in some way aesthetically jarring. Also the interactive plots it generated was rather barebones.
Plotting from a pandas dataframe seems more convenient way than using gnuplot presently.
Yes, from matplotlib, but much of the work of massaging the data into the right form is done with the dataframe, before calling matplotlib for plotting.
Yeah, I agree. Though actually I like plotting from Julia the best. You see software like gnuplot a lot: started its life just doing one thing and then slowly growing. The end result is an unholy mess of a system. All things eventually end of being Turing complete, so let's just eliminate the middle man and use a programming language.
Other examples of this are html/js, excel, vim, and bc.
A much better result can be achieved if you first design then language (or use an existing one) and just implement libraries to do what you want. A good example of this is Emacs.
Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Incidentally, I haven't encountered much gnuplot use nowadays. Maybe 10 years ago it was pretty popular in academia, but most have moved onto using Python and matplotlib for plotting, even if the models are written in something else. Matplotlib is truly terrible, but at least it comes with a sort of acceptable programming language.
when I run top on a login server on HPC systems, there's always a few gnuplots doing something.
> Matplotlib is truly terrible
If Matplotlib is now considered terrible, then at least it has advanced the standard expectation. When I started plotting stuff, choosing among plplot, plotutil, latex, gnuplot etc, Matplotlib was and remains a great choice. And it does what you prescribe:
> first design then language (or use an existing one) and just implement libraries to do what you want
Tangentially related: I've been working on a plotting tool (https://github.com/LaurentRDC/pandoc-plot) that supports many plotting toolkits. I recently added support for Plots.jl. I can't believe how SLOW it is to get from running a script to getting output. 10x slower than matplotlib, 100x slower than Gnuplot.
The first time you plot using Plots.jl it will take a long time as it compiles the package, and maybe even has to download things. But subsequent plots should be fast. Unless each time you run the script you are starting over again—but that's not the best way to use Julia.
Not really since it's dependent on its own scripting language. That's like saying Matplotlib is language independent, you just need to know its scripting language (Python).
When people say gnuplot (not GNUplot) is language independent, they mean it is not tied to the language in which you are creating the data that you are plotting (unlike a plotting library, such as Matplotlib). This means that when you move your simulation from Python to Fortran or Julia or C, you can use all of your gnuplot scripts unchanged. You don’t have to learn about a new plotting package or library. And that’s because it has its own scripting language.
I still don't see how this is different from matplotlib. You can also move your simulation to a different language and keep using matplotlib for plotting, with it's own scripting language Python.
I’ve used both Matplotlib and gnuplot extensively for visualizing the results of simulations and other tasks. I’ll try to briefly explain why I say that the gnuplot solution is portable while the Matplotlib solution is not.
You don’t get plots from Matplotlib just by using Python, nor even Python + numpy. You also have to learn the conventions of the Matplotlib library, including the horrendous mechanism for making and storing settings. This amounts to learning Matplotlib’s domain specific language, which is at least as onerous as learning gnuplot’s scripting language.
When you move your simulation project from Python to another language (and this is a common sequence, as people often prototype a calculation in Python but then want to make it bigger) you will be able to keep using your Matplotlib routines if your method was to store the simulation output in a file and, in a decoupled step, read and plot the file with a Python/Matplotlib program. This is a trivial form of portability that goes without saying. But you will have to maintain a Python + numpy + Matplotlib + [maybe more] ecosystem, with the Python world’s notoriously shifting set of dependencies. In contrast, gnuplot is a compiled, standalone program. There is no ecosystem to maintain.
If your plotting phase was not decoupled from the calculation, and you have plotting code in your simulation code to plot things on the fly, you have to start over. Obviously you can’t use this plotting code in your Fortran program. In contrast, gnuplot has universal interfaces through sockets, FIFOs, and files. You won’t have to touch the plotting code, just trivially rewrite the lines of code that, for example, open and talk through a socket.
Maybe, there is a disagreement about the license interpretation. For decades only debian adopted this view, and only in fairly recently (last two years?) did fedora drop readline support.
The alternative it uses is broken almost to the point of unsuitability (e.g. write any line long enough to wrap and try editing it)
If you get a rush from piping massive csv files into sed/awk/grep/tr/cut, then into wc/sqlite3/[etc], and are at all interested in plotting visuals of the results for yourself, please do yourself a favor and spend 30 minutes riding the learning curve of this wonderful program. IME, the docs are wonderful and kind to beginners who aren't afraid to cmd+f for the bits they're interested in.
After a couple hours of fiddling, you'll find getting a first stab at a graph faster in gnuplot than in excel. Then, you'll wonder about all that time you could have been saving your whole life. Like any other cli tool, its language takes a bit of grokking, but you can institutionalize your knowledge in scripts and carry them with you the rest of your life. Seriously, try it out.