pgf math error, division by zero

Question

I have a valid gnuplot function (plots fine in gnuplot), with pgfplots fails to use:

\documentclass{article}

\usepackage{graphicx}
\usepackage{pgfplots}

\begin{document}
\begin{figure}[H]
\pgfplotsset{width=0.8\textwidth, height=0.6\textwidth}
\pgfplotsset{samples=200}
\centering
\begin{tikzpicture}
\begin{axis}[mark=none, style=solid,
             enlargelimits=false, 
             xmin=0,xmax = 2.5,
             ymin=0,ymax = 2.5]
%
\addplot gnuplot{3*(x**(3-1))*exp(-x**3)};
%
\end{axis} 
\end{tikzpicture}
\end{figure}
\end{document}

The error is

PGFPlots: reading {testplots.pgf-plot.table}
! Package pgfplots Warning: Axis range for axis y is approximately empty; enlarging it (it is [0.0:0.0])
! Package PGF Math Error: You've asked me to divide `231.00105000000000' by `0.0', but I cannot divide any number by `0.0'.

Answer 1

The quick fix is to stay away from the part that makes the data explode. Hence if you provide the key domain=0:2.5 it works without any errors.

Initially I thought: The problem comes from the fact that the default domain of plotting the functions is ( as egreg mentioned) [-5,5]. Since negative numbers make the exponential term explode, (the first instance gives e^125 ).

However it gets weirder which makes me think that this is not just an overflow problem. For example starting from -5, using domain=-5:2 it gives the mentioned error but when this key is given as domain=-2.4:2 up to domain=-2.369:2 it gives this

\pgfplotsset{width=0.8\textwidth, height=0.6\textwidth}
\pgfplotsset{samples=200}

\begin{tikzpicture}
\begin{axis}[no marks, style=solid,
             enlargelimits=false, 
             xmin=-5,xmax = 2.5,
             ymin=0,ymax = 5,domain=-2.369:2]
%
\addplot gnuplot{3*(x**(3-1))*exp(-x**3)};
%
\end{axis} 
\end{tikzpicture}

Notice how the ymax is violated. Also if I try to increase the ymax value, it gives me a Dimension too large error. Even weirder, it starts to give Dimension too large error when we go past -2.369 towards higher values. But if I remove the ymax option completely I get

So after seeing that I've removed the ymax and let the original code run and I get surprisingly.

I guess something is choked during the axis limit calculation. So it might be a bug or an internal limitation.