15

I have very simple problem, and I also have a solution to the problem. But I am hoping for a better solution:) Consider the following code:

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{calc}
\begin{document}
  \begin{tikzpicture}
    \foreach \x in {1,2,3} {
      \coordinate (V\x) at ($(\x-1,0)$);
    }
    \foreach \x in {1,2} {          
      \draw[black] ($(V\x)$) -- ($(V{\x+1})$);
    }
  \end{tikzpicture}
\end{document}

In the first \foreach loop the calculation \x+1 works fine, however in the second loop the problem is that $(V{\x+1})$ expands to V{1+1} and not V2.. I hope there is way to avoid defining another variable to solve this.. I know I could solve this writing

\foreach \x in {1,2} {
   \pgfmathtruncatemacro{\y}{\x+1};
   \draw[black] ($(V\x)$) -- ($(V\y)$);
 }

But this feels like overkill to me :).. Is there a way to avoid using \pgfmathtruncatemacro here?

Håkon Hægland
  • 2,685

2 Answers2

14

The following should do the trick. You can compute values and assign them to macros.

\documentclass{article}
\usepackage{tikz}
\usetikzlibrary{calc}
\begin{document}
  \begin{tikzpicture}
    \foreach \x in {1,2,3} {
      \coordinate (V\x) at ($(\x-1,0)$);
    }
    \foreach \x [evaluate=\x as \sx using int(\x+1)] in {1,2} {
      \draw[black]
           ($(V\x)$) -- ($(V\sx)$);
    }
  \end{tikzpicture}
\end{document}
  • Thank you! This was a nice solution.. I was not aware of the evaluate option to the \foreach statement.. – Håkon Hægland Mar 06 '13 at 12:59
  • 5
    With evaluate you are drawing a line to (V2.0) and (V3.0) which is visible if you use nodes instead of coordinates. Either you need to add int(...) around \x+1 or use [count=\sx from 2] for directly getting integers. – percusse Mar 06 '13 at 13:08
  • @percusse Thanks. I'll update the solution. (I've only just started playing with evaluate.) –  Mar 06 '13 at 13:12
13

I'll start by saying that Marc's solution is the right way to solve this, but I thought it might be useful to explain why a solution is needed.

TikZ is pretty good at sending stuff to its mathematical parser, meaning that you can specify coordinates using expressions. And for more complicated stuff one has the calc library. But there are situations where it wouldn't expect an expression and so where it doesn't bother with the parser. One of these is node names. Since names themselves are not assumed to have any semantic meaning, there's not a sensible way to interpret them in the parser. Thus the node V1 is simply a name of two symbols and has no implied relation to the node V2. So when it encounters V{1+1}, TikZ has no logic that tells it that what you really meant was V2. In short, node names are not parsed as mathematical expressions.

However, node names are expanded. That is, since a node name is meant to be simply a string then TikZ passes node names through edef to try to expand any macros that happen to be lying around inside it. This is why V\x and V\sx do work.

Unfortunately, PGF's maths parser is not expandable and this is why one has to do the calculation first - either implicitly (as in Marc's solution) or explicitly (as in yours) - and then insert the result in the node name stored in an expandable macro. But there are other maths parsers around that are expandable and can be used in this context. In particular, the primitive \numexpr expands (when prefixed by \the), whence:

\documentclass{article}
%\url{http://tex.stackexchange.com/q/101134/86}
\usepackage{tikz}
\usetikzlibrary{calc}
\begin{document}
  \begin{tikzpicture}
    \foreach \x in {1,2,3} {
      \coordinate (V\x) at ($(\x-1,0)$);
    }
    \foreach \x in {1,2} {          
      \draw[black] (V\x) -- (V\the\numexpr\x+1\relax);
    }
  \end{tikzpicture}
\end{document}

works.

But as I said at the start, Marc's solution is better here as it doesn't mix methods: all the calculation is done by TikZ/PGF and so one is assured of consistency.

Andrew Stacey
  • 153,724
  • 43
  • 389
  • 751