5 ms·

> GNUplot is language independent Not really since it's dependent on its own scripting language. That's like saying Matplotlib is language independent, you jus

> GNUplot is language independent 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).

leephillips 6y ago
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.
- whyever 6y ago
  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.
  - leephillips 6y ago
    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.

leephillips 6y ago

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.

whyever 6y ago
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.
- leephillips 6y ago
  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.