Why does fixed point arithmetic like to error on parts of the code that aren't doing any math?

I am using the package to improve the calculation of some angles I have it printing out, but it is evaluating a node that is just a number and returning an error:

ERROR: FP error: Illegal character \c@pgf@counta  found in float number!.

--- TeX said ---
\FP@errmessage #1->\errmessage {FP error: #1!}

l.13   {};

--- HELP ---
From the .log file...

This error message was generated by an \errmessage
command, so I can't give any explicit help.
Pretend that you're Hercule Poirot: Examine all clues,
and deduce the truth by order and method.

\documentclass[convert = false, tikz]{standalone}
\begin{tikzpicture}[fixed point arithmetic]
  \node[label = x] {};

From the code above, we see that fp has an issue with this node. If I remove fp, there isn't a problem, but I want the package to be used later on in the code where there is an actual calculation.

  • 1
    Where do you actually need fp? On the labeled node path? The label key does some computations that are apparently forwarded to fp. You can move the fixed point arithmetic as an option to a path, i.e. \path[fixed point arithmetic] <fancy calculations>;, and don't use it on a node/a label. – Qrrbrbirlbel Jul 24 '13 at 20:06
  • @Qrrbrbirlbel it is being used in the calculation of an arc in draw let ... in but shouldn't this not have a problem with a node? I would think it should know where calculations occur. – dustin Jul 24 '13 at 20:08
  • 1
    AFAIK, fixed point arithmetic replaced all (?) PGF math functions with their fp counterparts (as a wrapper around the \FP… macros). The label key accesses the angular border of the node (it needs to know where to place the label). This uses the cos and sin functions (this is the reason you get the error message twice). The angle is calculated and result is stored in \c@pgf@counta. This \c@pgf@counta will be passed through the trigonometric functions to fp which doesn't like that. If you need fp only on the let … in part, use it only there. – Qrrbrbirlbel Jul 24 '13 at 21:14
  • @Qrrbrbirlbel that is what I ended up doing (applying it to specified syntax only). The weird thing is if I do all coordinates and label the them later from a draw command, there isn't a problem. \coordinate (x) at (1, 0); \draw (0, 0) -- (x) node[above] {x}; – dustin Jul 24 '13 at 23:30
  • 1
    above which sets anchor=south doesn’t need to calculate a polar coordinate. Using anchor=270 (even though the result is the same) triggers the error. For labels on circular unrotated nodes you can use the anchors instead of the compass directions, e.g. north instead of above (the default direction that is set with label position), north west instead of above left. – Qrrbrbirlbel Jul 25 '13 at 0:01

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 quick 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 fix using the etoolbox package is:

% You should have loaded tikz before this line!

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

\node at (P.90) {}; % or
\node[anchor=270] {};

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, say

\path[fixed point arithmetic] let <fancy calculations> in …;

If needed, you can construct a short-cut to that long option, say:

\tikzset{fp/.style={fixed point arithmetic={#1}},fp/.default=}


\documentclass[convert = false, tikz]{standalone}
\begin{tikzpicture}[fixed point arithmetic,
  every label/.append style = {font = \scriptsize},
  dot/.style = {inner sep = +0pt, shape = circle,
    draw = black, label = {#1}},
  small dot/.style = {minimum size = .05cm, dot = {#1}},
  big dot/.style = {minimum size = .1cm, dot = {#1}},
  \node[font = \scriptsize, small dot = {left: \(1\)}] (P) at (203.16381:3cm)

  \node[fill,minimum width=1cm,label = {[red]north west:nw}, label = {[green]above left:al}, label=north:n] (a){};
  \foreach \sty/\an in {white/north, green/135, red/north west}\path[draw=\sty,fill=black] (a.\an) circle [radius=.8pt];


enter image description here

enter image description here

  • So issuing \patchcmd\pgf@sh@reanchor{\c@pgf@counta}{\the\c@pgf@counta}{}{}, will allow me to use fp globally. This is what I am getting from reading your post. I do hope in a future update that node labelling can some how be removed from begin affected. – dustin Jul 25 '13 at 3:22
  • @dustin percusse has already opened a ticket at the bug report. It is just a matter of … months until a fix does make it in the official release version of PGF/TikZ. By the way, it does not only affect labels but every use of angular anchors by simply using at (<node name>.<any angle>) or, as commented above, in anchor=<any angle>. – Qrrbrbirlbel Jul 25 '13 at 3:31
  • @Qrrbrbirlbel Till Tantau is doing a huge work with bug fixes recently. So hopefully it will get fixed quickly. – cjorssen Jul 25 '13 at 8:30

TikZ uses the \counter=\length trick which would multiply the length (in pt) by 65536 to get an integer number of sp units (which egreg taught me). So it is very often that you can see the temporary TikZ counters \c@pgf@counta...d show up in the computations.

Here probably (I don't have the patience to wait for the \tracingall result), the polar coordinate computation involves a trigonometric computation and when fp takes over the math operations, it can't deal with it. Instead you can use the fpu library of TikZ itself which is also a little tedious to use but it's a native resident.

Here is an excerpt from a long code piece about how cosine operation comes to a halt.

\FPmul #1#2#3->\FP@callc \FP@mul #1{#2}{#3}

It was supposed to multiply the #2 and #3 and write it in #1 but #2 offends fp. This might be actually a bug in fixed point aritmetic library.

  • The particular error can be solved by doing \the\c@pgf@counta instead of \c@pgf@counta. Can fp trained to do this as well? – Qrrbrbirlbel Jul 24 '13 at 20:20
  • @Qrrbrbirlbel I think the problem comes from the fact that TikZ handles trigonometry very badly (often look up table) so to increase the precision switches to counter. It's not a problem for pgfmath because it checks wgether the argument is a counter or not but apparently forgot to switch back to length when calling fp. Oh and the answer to your question I really don't know. – percusse Jul 24 '13 at 20:23
  • A ticket is opened at sourceforge.net/p/pgf/bugs/255 for this in the PGF Bug Tracker – percusse Jul 24 '13 at 21:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.