2

The short version: when using \foreach \x in [remember=\x as \lastx], iterating in {1,...,3} works, but iterating in {1,2,3} doesn't.

I have read the manual paragraph on /pgf/foreach/remember but don't see anything indicating why this should be the case.

This is particularly troubling when iterating over multiple numeric variables, where x0/y0,...,xn/yn doesn't seem to work anyway. Of course, it's also a problem when your list just doesn't follow an arithmetic sequence.

MWE:

\documentclass{standalone}  % same outcome with article

\usepackage{tikz}

\begin{document}

\begin{tikzpicture}
  \draw (0, 0) node[above] {
    \foreach \x [
      remember=\x as \lastx (initially 0)
    ] in {1,2,3}
    {\x, \lastx;\quad}
  };
  \draw (0, -1) node[above] {
    \foreach \x [
      remember=\x as \lastx (initially 0)
    ] in {1,...,3}
    {\x, \lastx;\quad}
  };
  \draw (0, -2) node[above] {
    \foreach \x / \y [
      remember=\x as \lastx (initially 0),
      remember=\y as \lasty (initially 0),
    ] in {1/11,2/22,3/13}
    {$(\x,\y), (\lastx,\lasty)$;\quad}
  };
\end{tikzpicture}

\end{document}

MWE output: top line says "1, 0; 2, 0; 3, 0" (wrong); second line says "1, 0; 2, 1; 3, 2" (right); bottom line says "(1, 11), (0, 0); (2, 22), (0, 0); (3, 33), (0, 0)" (wrong, and no way to fix by converting to <code>...</code> notation))

I'd be inclined to deem this a bug if it weren't such a prevalent use case…

wchargin
  • 3,139

0 Answers0