3

The following MWE results in the error Dimension too large. Changing the upper limit of the domain to a smaller value like 120 gets makes this error disappear.

\documentclass{article}

\usepackage{pgfplots}

\begin{document}

\begin{tikzpicture} \begin{axis} [ domain=-20:150, ] \addplot+ {exp(-x*x)}; \end{axis} \end{tikzpicture}

\end{document}

But I cannot understand why. The largest number that should be involved in the calculation is 150^2, which is well in pgfplots' range (and in fact plotting x*x works just fine). My guess is that it has something to do with the implementation of exp that makes pgfplots try to compute exp(150^2) in the process of calculating exp(-150^2). However, the plot still appears just fine, so I'm not sure.

What is the reason for this error and how can I avoid it?


(Of course the real function I want to plot is a bit more complex, so just manually plotting y = 0 for x > 50 or something like that won't work. I need to solve/circumvent the underlying issue.)

schtandard
  • 14,892
  • I don't know why you get the error but changing 150 to 120 and everything works fine seems to indicate what you said: exp(150^2) calculation is probably the culprit. With respect to "how can I avoid it?" especially as you intend to work with more complex functions is to outsource the calculations to a more appropriate tool. See answers to problem of plotting a smooth function here. I prefer sagetex but other options mentioned might suit you better. – DJP Nov 24 '21 at 22:21
  • @DJP I think it is more complicated. When I use \pgfplotsset{compat=1.17} + LuaLaTeX (TeXLive 2021) + domain = 120:150 then it works but with \pgfplotsset{compat=1.10} is does not. – Dr. Manuel Kuehner Nov 24 '21 at 22:24
  • @Symbol1 This is maybe something that requires your skill set. (not sure if pinging works that way) – Dr. Manuel Kuehner Nov 24 '21 at 22:24
  • @DJP Oops, meant to include that detail in the question but forgot. You are right that outsourcing calculations like this to an external tool is the safest option, but this is not quite complex enough for me to bite that bullet. Especially as I don't understand why this particular limitation should exist. – schtandard Nov 24 '21 at 22:45
  • 1
    @Dr.ManuelKuehner Thanks for your investigation! This makes me think that I should open a bug report with the pgfplots people.. Oh, and I'm pretty sure pinging does not work that way. – schtandard Nov 24 '21 at 22:47
  • In fact, the problem is not in the computation of exp(-150^2) but simply with 150^2. pgf does all its computations using TeX dimensions which are limited to 2^14 = 128^2. 150^2 is simply too big. – Eric Domenjoud Nov 24 '21 at 23:13
  • @EricDomenjoud pgfplots uses the fpu library by default, so this is not an issue. As I mentioned, plotting x*x (which includes 150^2) works just fine. – schtandard Nov 24 '21 at 23:15
  • @DJP I added an example for 150^2 to my non-answer. – Dr. Manuel Kuehner Nov 24 '21 at 23:30
  • Do you consider the question answered? – Dr. Manuel Kuehner Nov 26 '21 at 19:11
  • @Dr.ManuelKuehner Well, partly. I would still be interested in a definite answer on the underlying issue, i.e. where in the implementation the overlarge dimension appears. (And maybe where to watch out for similar pitfalls.) This is why I didn't accept an answer yet. My immediate problem is solved, though. – schtandard Nov 26 '21 at 22:23
  • I see, I have a similar open question. IMHO, I would accept Stefan's answer. It does not get much better than having Stefan answer a pgfplots question. And the problem is solved when using modern LaTeX tools (Lua or I guess gnuplot). Anyway, you decide. – Dr. Manuel Kuehner Nov 26 '21 at 22:27

3 Answers3

3
  • Not an answer.
  • Just to make sure that there is no misunderstanding.
  • I plotted your example in MS Excel (be aware that the decimal separator is a comma, German language setting).
  • Is my screenshot in alignment with your expectations (or did I make a mistake)?

enter image description here

enter image description here


Update 1

  • There is some kind of dependency on the version/compiler.
  • Take the following code for example.

\documentclass{article}

\usepackage{pgfplots} \pgfplotsset{compat=1.17}

\begin{document}

\begin{tikzpicture} \begin{axis} [ domain = 120:130, % 120:121 works samples = 10, ] \addplot+ {exp(-x*x)}; \end{axis} \end{tikzpicture}

\end{document}

  • TeXLive 2020, pdfLaTeX: Error
  • TeXLive 2020, LuaLaTeX: Works
  • TeXLive 2021, pdfLaTeX: Error
  • TeXLive 2021, LuaLaTeX: Works
  • TeXLive 2021, LuaLaTeX: Error when using \pgfplotsset{compat=1.10}!

enter image description here

Update 2

150^2 seems to work!

\documentclass{article}

\usepackage{pgfplots} \pgfplotsset{compat=1.18}

\begin{document}

\begin{tikzpicture} \begin{axis} [ domain = 140:150, samples = 10, ] \addplot+ {x^2}; \end{axis} \end{tikzpicture}

\end{document}

enter image description here

3

As I commented above, sagetex is a good tool for more complicated mathematics. That's because it gives you access to a CAS and the Python programming language. Here is a quick sagetex implementation:

\documentclass[11pt,border=1mm]{standalone}
\usepackage{sagetex}
\usepackage[usenames,dvipsnames]{xcolor}
\usepackage{pgfplots}
\pgfplotsset{compat=1.16}
\begin{document}
\begin{sagesilent}
LowerX = -20
UpperX = 150
LowerY = -.1
UpperY = 1.1
step = .13
t = var('t')
g(x)= e^(-x^2)

x_coords = [t for t in srange(LowerX,UpperX,step)] y_coords = [g(t).n(digits=6) for t in srange(LowerX,UpperX,step)]

output = r"\begin{tikzpicture}" output += r"\begin{axis}[xmin=%f,xmax=%f,ymin= %f,ymax=%f,"%(LowerX,UpperX,LowerY, UpperY) output += r"xlabel=$x$,ylabel=$y$,axis x line=middle,axis y line=middle," output += r"grid style=dashed]" output += r"\addplot[thin, blue, unbounded coords=jump] coordinates {" for i in range(0,len(x_coords)-1): if (y_coords[i])<LowerY or (y_coords[i])>UpperY: output += r"(%f , inf) "%(x_coords[i]) else: output += r"(%f , %f) "%(x_coords[i],y_coords[i]) output += r"};" output += r"\end{axis}" output += r"\end{tikzpicture}" \end{sagesilent} \sagestr{output} \end{document}

The output in Cocalc is below: enter image description here

The sagetex package uses the Sage CAS. This is not part of the LaTeX distribution. The easiest way to get started is through a free Cocalc account.

DJP
  • 12,451
3

When I understand your question right then the answer is: This type of question is quite common here on TeX.SX. Here one possible solution to circumvent the problem. For details have a look at the comments in the code.

Here a list of similar questions I have answered with some other possibilities to (most likely) circumvent the problem as well.

% used PGFPlots v1.18.1
\documentclass[border=5pt]{standalone}
\usepackage{pgfplots}
    \pgfplotsset{
        % When using `compat` level 1.11 or lower TeX will be used as
        % calculation engine. This includes not stating `compat` at all.
        % Stating a `compat` level 1.12 or higher *and* compiling/TeXing with
        % LuaLaTeX uses Lua as calculation engine (when the equation satisfies
        % some requirements)
        % --> using 1.11 results in a "Dimension too large" error
        % --> using 1.12 and compiling with LuaLaTeX works just fine
        compat=1.12,
    }
\begin{document}
\begin{tikzpicture}
    \begin{axis}[
        domain=-20:150,
    ]
        \addplot {exp(-x^2)};
    \end{axis}
\end{tikzpicture}
\end{document}

image showing the result of above code

Stefan Pinnow
  • 29,535
  • You are right, this seems to be the issue. Can you explain why this is necessary here, even though there is no necessity for handling large numbers? Is this an implementation detail of exp, as I suspected? Or are very small numbers also an issue? (I would have though they just get rounded to 0.) – schtandard Nov 25 '21 at 10:36
  • 1
    Unfortunately I can't. I can only provide a solution for the problem and not the real/original route cause for the error. – Stefan Pinnow Nov 25 '21 at 10:50