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

`label`

it needs to find the appropriate point on the border of the labeled node. A direction of`left`

sets the anchor to the angle of`180`

. Later down in this process the macro`\pgf@sh@reanchor`

is used to find the actual coordinates of this point on the border.This macro first checks if

`180`

is a named anchor for this shape (like`north west`

or`base`

), 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.`180`

is then evaluated by`\pgfmathsetcounter`

). The result is stored in the count register`\c@pgf@counta`

(i.e. the LaTeX counter`pgf@counta`

).`\c@pgf@counta`

is then directly used on`\pgfqpointpolar`

. The`q`

denotes a “quick” version of the`\pgfpointplar`

macro which (the`q`

uick 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

`fixedpointarithmetic`

library and its option directly maps these trigonometric functions to their`fp`

counterparts.`fp`

does not tolerate registers.## A bug?

I consider this a bug in the definition of

`\pgf@sh@reanchor`

as seemingly every other use of`\pgfqpointpolar`

of PGF uses directly numbers or content that expands to a number.How to fix it?A

simple fixusing the`etoolbox`

package is:This also fixes the direct use of angular anchors as in (keeping with your example):

`west`

instead of`left`

For circular unrotated nodes you can actually use the compass anchors without a problem as they map directly to the directions. So instead of

`left`

you can use`west`

. 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 arithmetic`

for labels.Of course, for this little task the

`fp`

package and its precision are not needed, so if you can avoid it, use`fixed point arithmetic`

only on paths where you actually need it, sayIf needed, you can construct a short-cut to that long option, say:

## Code

## Output