Hacker News Reader

Comment by leephillips | Hacker News Reader

Gnuplot is designed to work with LaTeX. If you want a unified appearance, with textual elements on the graph typeset by TeX, then that workflow is built-in to gnuplot.

You can also use TikZ to call gnuplot from within the LaTeX document, or generate TikZ code from within gnuplot.

A very brief introduction:

https://lwn.net/Articles/628537/

View on HN

You can also use PGFPlots, a plotting tool built into LaTeX (using PGF/Tikz).

http://pgfplots.sourceforge.net/

It delivers nice vector graphics plots, and since it's in your .tex file, it automatically picks up any and all styling changes you have made in the preamble. You can have it re-render plots on each LaTeX compilation, or just conditionally re-render plots if the data has changed.

(As always, latexmk [ http://mg.readthedocs.io/latexmk.html ] comes highly recommended for automating the compilation of LaTeX documents.)

There's also a nice gallery of online pgfplot examples at http://pgfplots.net

I'd second the PGFPlots recommendation. Easy to create plots by hand or you can use matlab2tikz (mentioned but dismissed in the article) if you're coming from matlab.

I'd also second the latexmk recommendation!

I love matlab2tikz. I used it for all my plots in my Ph.D. thesis (and I had a lot). I also really like latexmk.

For non-plots I love Sketch (http://sketch4latex.sourceforge.net) which is pretty great for doing diagrams with 3D objects, especially if you use the sketch-lib (https://alexdu.github.io/sketch-lib/) which provides a bunch of useful simple objects to manipulate.

I have yet to see a solution that beats gnuplot+tikz+LaTex in image quality. It's also trivial to script and include in a makefile. If you drive it to extremes, this is also the only solution I know of that can do proper references inside the figure key, for example a citation with bibtex. (But beware: this is too much for most publishers)

That is extreme - but a nice example of the implications of tight LaTeX integration!

Good thing is that you don't even need a Makefile. If you use latexmk it can automatically run gnuplot [1]. It's very useful if you are in "continuous-preview" mode (aka automatic builds when you change the source of the document).

http://tex.stackexchange.com/questions/106512/gnuplot-in-lat...

I was aware of latexmk, but I didn't know it can run gnuplot too. That's great! Thanks!

You don't even need that, if you allow shell-escapes you can run gnuplot directly from your latex call.

org-mode is also worth looking into. You can execute code fragments and embed the results using Babel[1]. Makes it simple to use the output of e.g. gnuplot or matplotlib.

I am relatively new to org-mode (via Spacemacs). But I really like it, you can use it as a quick notebook to jot down things, run code, and export the result as PDF per LaTeX.

[1] http://orgmode.org/worg/org-contrib/babel/

There is another solution for having citations and references in figures: use Inkscape as suggested in the OP. In particular the save to pdf+latex feature. Any text elements in the figure are generated using latex. This means the correct font and the ability to write any latex you want as text. I still like hand editing figures to add complex annotations so I like being able to use Inkscape's GUI.

Gnuplot is something i categorise with Fortran and hand writing latex as "I use use it because my advisor used it, and he used it because his advisor used it...". I understand that they were once the best tool for the job and they still work, but better alternatives have emerged since, e.g. matplotlib, C++/numpy and LyX respectively. I know this is a subjective matter but i feel it's a shame that a lot of scientist don't shop around and hence end up stuck with the "classical" option.

Strange. I feel going in the opposite direction. Removing as many fancy latex packages from my documents as possible, because I am worried that my files can't be compiled 10-15 years from now.

I am a tex/latex survivalist :)

The good thing about latex is that it's pure text. While the ability for nice output might be lost, generally, the intent and content of the document is still extractable.

I "shopped around" and tried all of these things, and more. I returned to LaTeX and gnuplot because they are better. I'd certainly rather use modern array Fortran than C++.

Let's put it this way: I wrote my diploma thesis in LyX, but went back to emacs+latex for my PhD. I did not regret it. Matplotlib is close, but I get results with gnuplot quicker.

My students all started out using root/matlab/whatever for plots. Except for the matlab guy, sooner or later, they all switched to gnuplot. Not forced by me.

So you shopped around and stuck with the thing you like. That's great and nobody could argue with it. In my own department grad students and even wizened old professors are moving away from gnuplot and matlab to matplotlib, but I bet that having "experts" around is a more important factor than anything else.

Why do you quote the word experts?

It doesn't appear that the objective merits of the tools under discussion yield a single best answer. For example, if you look through various implementations of assorted somewhat-esoteric algorithms & formulae, I have found that the FORTRAN implementations are usually cleanest. Not because the language is cleaner or anything like that, but because the most experienced people in the field didn't see the point of bowing to language fashion.

If fashion were the deciding point I suppose we'd all be compelled to use JavaScript, so, yeah. I'd rather not reimplement something that already works right, least of all when it's a fiddle problem and I've got deadlines to hit.

I quoted it because, for example, within a small group, I would be the go-to person for "I need software that does X" or "I hate Y, what can I use instead?". I'm by no means an expert in, say, matplotlib, but I have local influence by means of my relative, perceived expertise.

You make a great point. The only thing that I'd add is that a lot of the Fortran code that I'd rely on (large venerable linear algebra and ODE packages) were written a long time ago, when it would have been somewhat less unfashionable.

Have you used Fortran? Have you tried f2py, which converts Fortran modules into NumPy compatible Python modules? I would rather use Fortran over C++ in a heartbeat for scientific computing. For what it's worth, I thought for years that Fortran was an old crusty language, not worthy of my time, choosing to use C++ instead, and I regret not picking it up sooner.

I have used Fortran in a few instances where I was compelled to. I never gave it much of a chance because I didn't like using it, and what's more it isn't nearly as popular as C/Python/Matlab etc. for modern stuff. If popularity (and hence code sharing) wasn't important I'd be using languages I like, like Haskell and Scheme.

All the same your comment makes me think I may have dismissed it too quickly so I'm going to give it another try for my next toy project (even if they index arrays from 1). Thank you.

You can index arrays in Fortran any way you want to.

Fortran is popular among people in many disciplines doing large-scale scientific computing. I was surprised to learn a few years ago that C++ had become popular in the high energy physics community; the emphasis there is on crunching vast amounts of data from experiments.

> even if they index arrays from 1

They don't have to! You can set the array index bounds to whatever you want. For example,

    real(8) A(0:n-1)
    real(8) w(-p:q)

are both valid declarations and would be indexed by i=0,n-1 and i=-p,q respectively. If you're using gfortran compile with the "-fbounds-check" flag to save a lot of headaches!

In modern Fortran, there is only really one big headache (coming from e.g. Python), and that's how hard string processing is, and how there are no generic lists. E.g. something as simple as cpnverting an integer to a string (or vice versa) actually uses I/O and writes/reads from the int to the string. (I have written Fortran code that outputs data both in JSON, CSV, proprietary binary formats and as XML at various points in time. It's not generally pleasant.)

If a hypothetical Fortran 201x added Python-esque generic lists and list/array comprehensions that played well with strings, and promoted strings to a "first class" type, I'd have a lot less reason for pulling in Python for scientific applications not involving web/graphics.

Reply on news.ycombinator.com