# pgfplots plots function not correct

This code

\documentclass{article}

\usepackage{pgfplots}

\begin{document}

\begin{tikzpicture}
\begin{axis}
\end{axis}
\end{tikzpicture}

\end{document}


plots a heavily oscillating function. If I plot this function with another plotter (Mathematica, online plotters, ...) I get a really smooth function that is the non-oscillating mean of the function that pgfplots gives.

I know that pgfplots uses degrees instead of radians, but asin() should give degrees then, I assume (so that rad() is not neccessary)? Anyways, I already tried to put rad() in all possible combinations, it often changed the output, but it never gave the correct result.

Changing the samples to 1000 gave no better result either (it started oscillating even faster). Is this a bug of pgfplots?

Are there any other options to try/change here?

Result with TikZ version 2.10 (constant interpolation):

Result with TikZ CVS version ≥ 2012-10-11 (linear interpolation):

• The answer of @Jake is correct. The pgfmath* routines use table lookup with constant interpolation. Changing to linear interpolation significantly reduces the error, although it is still not precise enough. I will check if I can do something about it. – Christian Feuersänger Oct 11 '12 at 9:06
• @ChristianFeuersänger Good work! I added two pictures to show result before (constant interpolation) and after (linear interpolation) your patch. – Paul Gaborit Oct 14 '12 at 13:32

This is pushing the pgfmath engine (and its approximations for the trigonometric functions) past its limits, I believe. You can work around the issue by using gnuplot as the backend instead:

\documentclass{article}

\usepackage{pgfplots}

\begin{document}

\begin{tikzpicture}
\begin{axis}
\addplot [no markers] gnuplot [domain=15:30, samples=100] {4*65*sin(0.25*asin(x/65))/x};
\end{axis}
\end{tikzpicture}

\end{document}

• Thanks. Gnuplot solved this. By the way, is there any situation where gnuplot is the worse choice over pgfmath? – Foo Bar Oct 10 '12 at 19:03
• No, the speed is almost negligeble for small plots, for large plots gnuplot calculates a lot faster. As for precision gnuplot is more accurate in any case (pgfmath will only match, not outperform gnuplot). – zeroth Oct 10 '12 at 19:06
• @Foo Bar: Well, there are some drawbacks: you need to give TeX file system access, and using gnuplot makes your .tex files less portable (not everyone has gnuplot installed). – Jake Oct 10 '12 at 19:19

This is largely a follow-up to @Jake:

if you don't want to use gnuplot inline (for the required write access, as this makes building more complex), you can precompute the curves very easily, and use

\draw plot file { yourfile.table };


where you can generate the precomputed tables once with gnuplot, e.g.

#!/usr/bin/gnuplot
set format "%.6f"
set table "yourfile.table"
set samples 100
plot [x=15:30] 4*65*sin(0.25*asin(x/65))/x


or with a custom application.

The main benefits are that you can a) use arbitrary other applications to generate the data, b) it only needs to be run once and c) you don't need extra permissions or parameters for your pdflatex call.

The main drawback is that the formula no longer is inline in the tex file; to change anything you need to work outside your tex.

This thread is quite old and there is an update.

First: compiling the plot in question with pdflatex has the accuracy difficulties for this challenging function and the other answers are valid.

However, the version 1.12 of pgfplots comes with a lua backend which uses lua's advanced math functions. Compiling the example in question with lualatex results in the expected output (without accuracy problems). It is also at least twice as fast.

The lua backend is active if one uses compat=1.12 or newer. Most of the standard parameter combinations are supported, if some combination is currently unsupported, pgfplots will automatically use the existing TeX implementation.

Advantage of this solution: no 3rd party libraries needed.