In trying answer Is it possible to use a macro to name a TikZ node?, I attempted to use the solution provided at pgfmath expansion - call a command from within a pgfmath environment, but this yielded the error message

Incomplete \iffalse; all text was ignored after line 67.
<inserted text>

from the example


    \pgfmathparse{#2 + \mymathresult}%

    \node (0) at (0,0) {X};
    \node (\mymacro{2}{3}) at (1,2) {Y};
    \draw (\mymacro{2}{3}) -- (0);
    \draw (5) -- +(3,0) {Z};

The problem in pgfmath expansion - call a command from within a pgfmath environment is the same as here: a \pgfmathparse command, which is not expandable, is being used somewhere where it wants to be expanded. In that case it is within another \pgfmathparse. In this case, the real problem is in the node name itself. The solution avoids the expansion issue by first processing the macro outside an "expansion context" (not sure if that's the right term! I mean that it is in the normal run of TeX and not in an \edef.) and then using the result of that in the expansion place. Thus:


fails but the solution is to do:


That solution would work here as well, but its implementation would be:


% You wait.  Time passes.  Thorin sits down and starts singing about gold.

\node (\nodename) at (1,2) {Y};

The point here is that we have to avoid putting anything unexpandable in the brackets. So all the \pgfmathparse routines have to be executed before we get to that point. No matter how you dress it up, \node (\mymacro{2}{3}) executes \mymacro in the \edef that sets the node name and so all the workings of \mymacro are evaluated at that point.

To do it all in one step would require an expandable version of \pgfmathparse. For particular circumstances, such as that in the original question, one can use the integer routines from LaTeX3 (texdoc source3).


Node names need to be expandable, as they are used inside an \edef. The pgf maths processor is not expandable, and so as constructed this cannot work. You need to evaluate the result first. However, there is a second issue, as the result of the calculation is 5.0. Try for example

    \node (0) at (0,0) {X};
    \node (5.0) at (1,2) {Y};
    \draw (5.0) -- (0);

which fails on the \draw line looking for a non-existent label 5.

Over all, this suggests to me that labels really do need to be controlled by hand.

  • Perhaps one of the Tikz gurus will do better: there may be a way around this, but to me the message is 'write out your labels'. – Joseph Wright Sep 8 '11 at 5:24
  • THanks. I was aware that the 5.0 as computed in the MWE needed to be converted to integer, but was not aware that 5.0 as a label would not work. – Peter Grill Sep 8 '11 at 5:35
  • 1
    Actually, 5.0 works as a label, it just can't be used again as a coordinate because there is a step in the coordinate parser that looks for the syntax name.anchor so 5.0 gets interpreted as "the anchor which is at angle 0 on the boundary of the node called '5'". – Loop Space Sep 8 '11 at 7:06

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.