3

MNWE:

\documentclass{article}
\usepackage{forest}

\begin{document}
\begin{forest}
  for tree={circle,draw}
  [1[2[3][4]][5]]
\end{forest}
\end{document}

With Texlive 2019, I get the following error:

! Dimension too large.
<recently read> \pgf@x 

l.28 \end{forest}

The code compiles fine with Texlive 2018. (Not sure whether I got the final updates for TL2018). The files forest.sty are identical in TL2018 and TL2019.

What's changed to cause the error? Is it a bug? If so, in what and where?

cfr
  • 198,882
  • That's really odd. If one drops, say, [4], the error is gone. –  Oct 26 '19 at 02:12
  • @Schrödinger'scat Yes, I know. Or circle. – cfr Oct 26 '19 at 02:13
  • Though you could drop draw, so the example isn't ideally minimal. – cfr Oct 26 '19 at 02:14
  • 1
    for tree={circle,draw,rotate=1} also removes the error. Rotating a circle helps? Strange. ;-) If you rotate by 45, 90, 180 or so on, the error comes back. –  Oct 26 '19 at 02:14
  • @Schrödinger'scat Even rotating the circles by 0.1 removes it. – cfr Oct 26 '19 at 02:16
  • 1
    Anything but a integer multiple of 45 seems to work.... –  Oct 26 '19 at 02:17
  • 1
    The same happen with recent MikTeX. – Zarko Oct 26 '19 at 02:37
  • @Zarko Weird, isn't it? – cfr Oct 26 '19 at 02:39
  • @cfr, yes, it is. No so long ago I wrote similar forest tree and it has worked. I do not know with which MikTeX upgrade this change. – Zarko Oct 26 '19 at 02:46
  • 2
    I think I may have isolated the error: it seems to come from the lines \divide\c@pgf@counta by 255\relax% \pgf@ya=16\pgf@ya\relax% \divide\pgf@ya by\c@pgf@counta% \pgf@xa=16\pgf@ya\relax% in pgfmoduleshapes.code.tex. –  Oct 26 '19 at 03:11
  • @Schrödinger'scat A diff of the 2018 and 2019 file doesn't include the word divide so those lines in themselves haven't changed. (Which doesn't mean that's not where the error's coming from, of course.) – cfr Oct 26 '19 at 03:30
  • I only found that if I remove this the error goes away. But you are right, adding \typeouts does not reveal anything that is very different when one adds small rotation angle. The error is not necessarily in the \divide but perhaps in the \pgf@x=\pgf@xa% that follows, but I cannot see how \pgf@xa is too large. (Unfortunately I cannot do a diff because I do not have the older versions available.) –  Oct 26 '19 at 03:33
  • @Schrödinger'scat https://pastebin.com/Btuh8UZ4 – cfr Oct 26 '19 at 03:36
  • Can you copy the old file pgfmoduleshapes.code.tex to the directory in which you compile the document? Does that help? –  Oct 26 '19 at 03:48
  • @Schrödinger'scat Scratch my last comment. I left a rotate in my code. Dropping that file in doesn't help. The error stays the same. – cfr Oct 26 '19 at 03:52
  • 2
    There have been some changes in pgf's floating point unit, maybe that's the culprit. – Sašo Živanović Oct 26 '19 at 05:30
  • 1
    @SašoŽivanović I appreciate your looking. – cfr Oct 26 '19 at 13:37
  • Sorry for spamming, but it seems so be related to intersections. If I add \tracingmacros=1, at the very end before the error one finds \pgf@intersect@len@a which comes from the pgf module intersections. A bit above one finds \pgfmathresult ->{-619.9691000000000}{2904.08000000000} which become \pgfmathresult ->{119.74692000000000}{-559.422000000000} for rotate=0.1. @SašoŽivanović And it is true that right before there is \pgfmathfloattofixed@impl@pos. So maybe this is some interplay between intersections and floating point numbers? –  Oct 26 '19 at 15:15
  • @cfr That was not looking, but guessing. ;-) I'm afraid I'm not at my desktop this weekend, and I still have TeXLive 2018 on my laptop ... – Sašo Živanović Oct 26 '19 at 15:18
  • 1
    @Schrödinger'scat Yes, intersections are heavy users of fpu. – Sašo Živanović Oct 26 '19 at 15:19

1 Answers1

2

I believe that ultimately, the error occurs for the same reason as with nice empty nodes style: \pgfintersectionofpaths yields an error when the lines it is trying to intersect are almost parallel. See the original question on this issue and the bug report in PGF's GitHub repo.

In this case, the trigger for the error seems to be the improved version of PGF'S \pgfpointnormalised (introduced in commit 65b8261c, released in PGF 3.1.2), which is called from the declaration of shape circle in pgfmoduleshapes.code.tex. It makes sense: a more precise function yields more nearly parallel lines and thus makes the intersecting fail more often.

(The bug report on \pgfintersectionofpaths is open for four years now but had not yet been addressed. For a good reason, I guess, as it seems a very hard issue to fix, certainly above my league. I hope the new "application" of the bug encourages work on it. I'm adding a link to this answer to the bug report.)

Sašo Živanović
  • 11,732