TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Update: This has problems if the samples are one of these: {19,21,23,28,30,31,32,34,36,38,39}, so I think something else is going on.

I can get this example to work fine if I reduce the number of samples to 40 or below. Otherwise, this results in an incorrect graph. I am wondering if this seemingly huge round off problem might indicate that there is some other underlying problem with the math engine. So, is this a know issue, and I just have to make sure that I adjust the number of samples based on what is being plotted?

The MWE example below produces the following output as it stands now, when it should just be a straight line.



\begin{axis}[xmin=-4,xmax=+0, ymin=-0.5,ymax=4.5] 

\addplot[draw=blue, mark=none, ultra thick, domain=-4.0:-0.1,
         samples=100] % Fine is sample < 42, and NOT {19,21,23,28,30,31,32,34,36,38,39}
    {(3*x + abs(x))/x}
    node [midway, above right] {$y=\frac{3x + |x|}{x}$}; 


Update 2011-11-03: Am not able to reproduce this behavior with the current TeXLive2011 release, so problem is definitely fixed.

share|improve this question
I get the same output with a freshly updated TeXLive. – Martin Scharrer May 18 '11 at 22:58
on a side note: I have seen artefacts like the one at x=-1.5 in "real life" as a result of over-sampling of a data acquisition card run at high frequencies... – Martin H May 18 '11 at 23:30
Since the problem occurs at even small sample sizes like 19, I don't think this is a problem with just over sampling. – Peter Grill May 19 '11 at 0:02
It works without errors in the development version, but I wasn't able to find the commit that fixed this. – Jake May 19 '11 at 5:19
up vote 5 down vote accepted

Seems as if this is (was) a bug in pgf/tikz: on my machine, I get a straight line.

I can confirm that this happens with pgf 2.10 and the stable version(s) of pgfplots.

It vanishes for pgf 2.00 and/or for pgf CVS.

I have just uploaded an unstable version of pgfplots which incorporates the pgf 2.10 bugfix: your example will work with the unstable pgfplots version from http://pgfplots.sourceforge.net/ and pgf 2.10 as well.

So, to solve the problem in your application, I see the following approaches:

  1. use the unstable of pgfplots (which is pretty stable now)
  2. use pgf CVS
  3. downgrade to pgf 2.00
  4. use \addplot gnuplot instead and enable the shell-escape feature.

Note: Installing pgf CVS or pgf 2.00 manually is more complicated than installing pgfplots since pgfplots comes in a TDS structure (which is compatible with local texmf installation directories). The pgf versions need to be adjusted manually before TeX distributions accept them as TDS.

share|improve this answer

It seems that tikz has some problems with the calculation. Probably it is a rounding error?

As a work around you could -shell-escape to gnuplot and let gnuplot do the calculation



 \addplot[draw,mark=none] gnuplot[raw gnuplot] {set xrange[-4:4];
plot (3*x+abs(x))/x};


enter image description here

share|improve this answer
Rounding error it mat be: since TikZ uses TeX's dimen registers internally, this is 32 bit fixed point arithmetic. – Bruno Le Floch May 19 '11 at 2:32
Rounding??? Its got to be quite a cumulative rounding error to get from 2 to almost 1. I think it must be something other problem. – Peter Grill May 19 '11 at 5:26

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.