I am definitely unfamiliar with both beamer and tikz (do not quite get what the \only are supposed to do) but perhaps this could go in the direction you want:
\documentclass{beamer}
\usepackage{tikz}
\usetikzlibrary{chains}
\newcounter{count}
% helper macro:
\long\def\GobToSemiColon #1;{}
\newcommand\myPicture{
\begin{tikzpicture}
\begin{scope}[start chain = going below]
\ifnum\value{count}<1 \expandafter\GobToSemiColon\fi
\ifnum\value{count}>3 \expandafter\GobToSemiColon\fi
\node[draw, rectangle, on chain] {display only when counter is between
1 and 3};
\ifnum\value{count}>-1 \expandafter\GobToSemiColon\fi
\node[draw, rectangle, on chain] {display only when counter is
negative};
\ifnum\value{count}<100 \expandafter\GobToSemiColon\fi
\ifnum\value{count}>200 \expandafter\GobToSemiColon\fi
\node[draw, rectangle, on chain] {display only if counter is between
100 and 200};
\ifnum\value{count}<3 \expandafter\GobToSemiColon\fi
\ifnum\value{count}>20 \expandafter\GobToSemiColon\fi
\node[draw, circle, on chain] {only when counter is in the range 3 to 20};
\end{scope}
\end{tikzpicture}
}
\begin{document}
\begin{frame}
\only{\setcounter{count}{-3}\myPicture}
\only{\setcounter{count}{105}\myPicture}
\only{\setcounter{count}{39}\myPicture}
\only{\setcounter{count}{2}\myPicture}
\only{\setcounter{count}{5}\myPicture}
\end{frame}
\end{document}
I don't quite know why the maths seems to fail in this case (although I suppose I should), but it seems it is not a problem with the way TikZ/PGF does maths, it is something to do with way trees are constructed.
Unfortunately, I haven't been able work out what the problem is exactly, but the fact that the problem is not the accuracy of mathematical calculations per se, can be demonstrated by using the same calculations outside of a tree:
\documentclass[tikz, border=5]{standalone}
\tikzset{bcir/.style={circle,fill=black,
minimum size=4pt,inner sep=0}, every node/.style={bcir}}
\begin{document}
\begin{tikzpicture}[every node/.style={bcir, anchor=center}]
\node {} child [grow=\g, level distance=\l cm] foreach \i [evaluate={%
\k=tan(5)*\i; \g=-atan(\k); \l=3/cos(\g);}]
in {0,...,13} { node {} };
\foreach \i [evaluate={%
\k=tan(5)*\i; \g=-atan(\k); \l=3/cos(\g);}]
in {0,...,13} { \draw [red] (0,0) -- (\g:\l) node [bcir,fill=red]{}; }
\end{tikzpicture}
\end{document}
So there must be something else going on.
In any event I think you are making a lot of work out of something that could be done much more simply with a custom growth function.
The following shows an example of the grow via three points growth function from the trees library.
\documentclass[tikz, border=5]{standalone}
\usetikzlibrary{trees}
\tikzset{bcir/.style={circle,fill=black,
minimum size=4pt,inner sep=0}, every node/.style={bcir}}
\begin{document}
\begin{tikzpicture}[grow via three points={%
one child at (3,0) and two children at (3,0) and (3,-1/4)
}]
\node {} child foreach \i in {0,...,13} { node {} };
\end{tikzpicture}
\end{document}
Best Answer
What happened?
When TikZ processes a
labelit needs to find the appropriate point on the border of the labeled node. A direction ofleftsets the anchor to the angle of180. Later down in this process the macro\pgf@sh@reanchoris used to find the actual coordinates of this point on the border.This macro first checks if
180is a named anchor for this shape (likenorth westorbase), if it isn’t it is checked whether the anchor is a generic one. If it isn’t even a generic anchor it only can be a angular point on the border.180is then evaluated by\pgfmathsetcounter). The result is stored in the count register\c@pgf@counta(i.e. the LaTeX counterpgf@counta).\c@pgf@countais then directly used on\pgfqpointpolar. Theqdenotes a “quick” version of the\pgfpointplarmacro which (thequick version that is) does not parse its arguments but directly sends them to the the trigonometric functions. Usually this parsing and evaluating is done by PGF math which automatically detects registers like counts/counters, dimens and lengths/skips and properly expands them to their value (stripping away any units).But the
fixedpointarithmeticlibrary and its option directly maps these trigonometric functions to theirfpcounterparts.fpdoes not tolerate registers.A bug?
I consider this a bug in the definition of
\pgf@sh@reanchoras seemingly every other use of\pgfqpointpolarof PGF uses directly numbers or content that expands to a number.How to fix it?
A simple fix using the
etoolboxpackage is:This also fixes the direct use of angular anchors as in (keeping with your example):
westinstead ofleftFor circular unrotated nodes you can actually use the compass anchors without a problem as they map directly to the directions. So instead of
leftyou can usewest. This will trigger the named anchors and avoids\pgfqpointpolar.This usually does not work for other shapes, at least for the diagonal directions, as can be seen in the second TikZ picture.
Or you don’t use
fixed point arithmeticfor labels.Of course, for this little task the
fppackage and its precision are not needed, so if you can avoid it, usefixed point arithmeticonly on paths where you actually need it, sayIf needed, you can construct a short-cut to that long option, say:
Code
Output