# \pgfmathsetmacro - dimension too large (biggest value allowed?)

I want to import some data with parameters to parametrize some plots. After importing a table, I assign specific variables of the table to a placeholder by using \pgfplotstablegetelem. And it works fine. Until some values getting to big:

Apparently the command \pgfmathsetmacro doesn't like values bigger than 16383 - an error dimension too large appears. Is there a reason why? And is it possible to increase that threshold such that also numbers in the 50000-range are excepted?

\documentclass{standalone}
\usepackage{pgfplots,pgfplotstable}

\begin{document}
\begin{tikzpicture}[declare function={test(\tmp) = x/\tmp;}]
\begin{axis}[samples=100,domain=0:1]
\pgfmathsetmacro{\tmp}{16383}
% \pgfmathsetmacro{\tmp}{16384} % Error
\end{axis}
\end{tikzpicture}
\end{document}

I've checked other dimensions too large postings here but haven't found a satisfying answer yet. Maybe you can help me. Thanks!

You can use the fpu library that ships with TikZ and that pgfplots uses internally. It allows calculations in the range from -1*10^324 to 1*10^324:

\documentclass{standalone}
\usepackage{pgfplots}

\begin{document}

\pgfkeys{/pgf/fpu}
\pgfmathparse{16383+1}
\edef\tmp{\pgfmathresult}
\pgfkeys{/pgf/fpu=false}

\begin{tikzpicture}[declare function={test(\tmp) = x/\tmp;}]
\begin{axis}[samples=100,domain=0:1]
\end{axis}
\end{tikzpicture}
\end{document}

From the pgf manual 2.10csv page 694:

It should be noted that all calculations must not exceed ±16383.99999 at any point, because the underlying computations rely on TeX dimensions. This means that many of the underlying computations are necessarily approximate and that in addition, are not very fast. TeX is, after all, a typesetting language and not ideally suited to relatively advanced mathematical operations. However, it is possible to change the computations as described in Section 76.

From the TeX Book page 114:

16383.99998 pt (TeX’s largest dimen)

In Notes On Programming in TeX Chirstian Feuersänger pointed out

The \dimen registers perform their arithmetic’s internally with 32 bit scaled integers, so called ‘scaled point’ with unit sp. It holds 1 pt = 65536 sp = 216 sp. One of the 32 bits is used as sign. The total number range in pt is [−(230 − 1)/216, (230 − 1)/216 ] = [−16383.9998, +16383.9998]1.

1 Please note that this does not cover the complete range of a 32 bit integer, I do not know why

• ok thanks. just for curiosity: where does the ±16383.99999 come from? Changing the mathematical engine won't really solve my problems, so I better change the input data. But thanks anyway! – kromuchi May 6 '12 at 22:05
• pgf uses TeX dimensions to do its mathematics. They are integers in units called 'scaled points', with a maximum of 2^32 - 1. The conversion to points comes out to the limit of ±16383.99999. – Joseph Wright May 7 '12 at 6:11

I want to note my old question "Missing number" error using \pgfmathsetmacro with the ifthenelse operator, in which I observed another inconsistency in \pgfmathsetmacro. Effectively, according to the accepted answer, this command can only set the macro in question to a TeX dimensions. Thus, it is constrained by the limitations of TeX arithmetic in addition to the limitations of being numerical in the first place. In particular, your code would work with the construct \pgfmathparse{16384}\let\tmp\pgfmathresult even though that value exceeds TeX's capabilities, because pgfplots uses the floating-point library and handles big numbers.

• Good to know. I somehow solved my problem in a different way but who knows one I have to deal with big numbers again. – kromuchi Aug 12 '13 at 15:13
• @Ryan Reich, could you help me on my question tex.stackexchange.com/questions/422561/… I don't know how to use you one line solution in my case. – user565739 Mar 23 '18 at 17:45
• @user565739 I'm afraid I can't; I don't use TeX anymore and can't answer questions about it. – Ryan Reich Mar 23 '18 at 18:30