The following example works well tikz up to 3.0.0 (TL 2014 and probably 2015), but breaks since tikz 3.0.1a (till now):

Start image
\begin{tikzpicture}[inner sep=0pt, inner ysep=0.3ex]
  \path let \p1 = (0,4), \p2 = (0,8) in node (foo) at (0,0+\maxof{\y1}{\y2}) {Hello};

with the following error:

! Missing number, treated as zero.
<to be read again> 
l.8 ...,8) in node (foo) at (0,0+\maxof{\y1}{\y2})

By copying only one file (pgfmathparser.code.tex) from the old installation to the new one the example starts working again.

Is this a known problem?


  • Thanks for the link. I thought I exchange the \maxof{}{} with max(,) but that didn't work either. – norbert May 7 '18 at 6:59
  • 5
    (0,{0+ max(\y1,\y2)}) works for me (at least it doesn't gives and error). – Ulrike Fischer May 7 '18 at 7:05
  • Huu, some comments got lost here ... strange – norbert May 8 '18 at 3:31

In the newer pgf-version the compability code for calc has been moved from \pgfmathparse@ to a more "inner" command and this breaks in the token processing. If I add the code again to \pgfmathparse@ it works again:


\xpretocmd\pgfmathparse@{\let\maxof=\pgfmath@calc@maxof}{}{\fail} %and so on
Start image
\begin{tikzpicture}[inner sep=0pt, inner ysep=0.3ex]\tracingmacros=1
  \path let \p1 = (0,4), \p2 = (0,8) in node (foo) at (0,{0+\maxof{\y1}{\y2}}) {Hello};
  \path let \p1 = (0,4), \p2 = (0,8) in node (foo) at (0, 0+\maxof{\y1}{\y2}) {Hello};
  \path let \p1 = (0,4), \p2 = (0,8) in node (foo) at (0,{0+ max(\y1,\y2)}) {Hello};

But I don't know the why the code was moved, so it could have unwanted side-effects. It is also possible that there is a better place for the code somewhere in the middle of the two locations.


I found the commit which made the change. It was done while implementing a "fast lane":

added automatic "fast lane" to math parser:

if the input is a number without units, it will return that as-is. Reduces typesetting time down to 66% for huge scatter plots and has just 1% overhead for math intensive figures.

Imho the code wasn't moved by purpose into the inner command but more or less accidental as the new inner command was written by changing the existing pgfmathparse@ and moving the calc-compability code back to pgfmathparse@ should work fine.

  • I don't think there was an intention to support calc package in the first place. – percusse May 7 '18 at 9:39
  • @percusse: The code is there already in 2014: % Stuff for calc compatiability. \let\real=\pgfmath@calc@real \let\minof=\pgfmath@calc@minof \let\maxof=\pgfmath@calc@maxof and so on. – Ulrike Fischer May 7 '18 at 9:43

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.