DerforestHandbuchdefiniert zwei Stile: sn edgesund nice empty nodes. Sie werden wie folgt definiert:
sn edges/.style={for tree={parent anchor=south, child anchor=north}}
Und
nice empty nodes/.style={for tree={calign=fixed edge angles},delay={where content={}{shape=coordinate,for parent={for children={anchor=north}}}{}} }
jeweils.
Wenn beide Stile mit dem folgenden Baum verwendet werden, erhalte ich die folgende Fehlermeldung:
! Package PGF Math Error: You asked me to calculate `1/0.0', but I cannot divid
e any number by zero.
See the PGF Math package documentation for explanation.
Type H <return> for immediate help.
...
l.51 \end{forest}
Weiß jemand, was los ist? Wie kann ich das beheben?
MWE
\documentclass{article}
\usepackage{forest}
\forestset{
sn edges/.style={for tree={parent anchor=south, child anchor=north}},
nice empty nodes/.style={for tree={calign=fixed edge angles},delay={where content={}{shape=coordinate,for parent={for children={anchor=north}}}{}}}
}
\begin{document}
\begin{forest} nice empty nodes, sn edges
[TP
[{the ball} ]
[
[T ]
[PrP
[{$<$the ball$>$} ]
[
[Pr ]
[VoiP
[{$<$the ball$>$} ]
[
[Voi ]
[AffP
[{to Mary} ]
[
[Aff ]
[ThP
[{$<$the ball$>$} ]
[
[Th ]
[AgP
[{by John} ]
[
[Ag ]
[$\surd$throw ]
]
]
]
]
]
]
]
]
]
]
]
]
\end{forest}
\end{document}
Aktualisieren
Interessanterweise wird es ohne Fehler kompiliert, wenn alles unterhalb des AffBlattes gelöscht wird. Das heißt, das Folgende wird kompiliert:
\begin{forest} nice empty nodes, sn edges
[TP
[{the ball} ]
[
[T ]
[PrP
[{$<$the ball$>$} ]
[
[Pr ]
[VoiP
[{$<$the ball$>$} ]
[
[Voi ]
[AffP
[{to Mary} ]
[
[Aff ]
]
]
]
]
]
]
]
]
\end{forest}
Antwort1
Zunächst eine Anmerkung: Der Fehler tritt auch ohne sn edgesStil auf.
Ich glaube, das ist kein forest, sondern eher ein Fehler. Ich habe das Problem auf die Bibliothek von pgfzurückgeführt . Der folgende Code reproduziert den genauen Fehler ohne .\pgfintersectionofpathspgfintersectionsforest
\pgfintersectionofpaths{%
\pgfpathmoveto{\pgfpoint{0.0pt}{-3.53297pt}}
\pgfpathlineto{\pgfpoint{19.54204pt}{-31.44316pt}}%
}{%
\pgfpathmoveto{\pgfpoint{34.6372pt}{-53.00208pt}}%
\pgfpathlineto{\pgfpoint{19.54204pt}{-31.44316pt}}}
Ich habe die Sache etwas genauer untersucht. \pgfintersectionofpathsruft auf \pgfpointintersectionoflines, was den Schnittpunkt zweier Linien berechnet, indem eine Koordinatentransformation auf einen bestimmten Punkt angewendet wird. Die mathematischen Details der beiden „einige“ im vorherigen Satz sind nicht wichtig, außer der Tatsache, dass der letzte Schritt in PGFs Berechnung der relevanten Transformationsmatrix die Inversion einer anderen Matrix ist, indem aufgerufen wird \pgftransforminvert. Dies \pgftransforminvertschlägt fehl, da die Matrix, die es invertieren möchte, nahezu singulär ist. Das PGF-Handbuch (S. 641) warnt, dass dies passieren wird:
Dieser Befehl erzeugt einen Fehler, wenn die Determinante der Matrix zu klein ist, d. h. wenn die Matrix nahezu singulär ist.
Aber warum ist die Matrix nahezu singulär? Weil die Liniensegmente, die wir schneiden möchten, nahezu parallel sind. An diesem Punkt schien es mir, als ob die Ursache des Problems die numerische Präzision von TeX wäre. Allerdings ...
Bevor der Schnittpunkt von Linien durch Aufrufen berechnet wird \pgfpointintersectionoflines, \pgfintersectionofpathswird versucht, festzustellen, ob sich die Linien schneiden: Dies geschieht in der \if-ähnlichen \pgfiflinesintersect. Ich glaube also, das Problem liegt darin, dass \pgfiflinesintersectbehauptet, dass sich die Linien schneiden, aber \pgfpointintersectionoflinesbei der Berechnung des Schnittpunkts fehlschlägt. (Der Code von \pgf@iflinesintersectenthält die Bemerkung „16384 ist möglicherweise keine robuste Wahl.“, wobei 16384 eine Konstante ist, die in einem internen Normalisierungsprozess verwendet wird. Könnte dies die Ursache des Problems sein?)
Als ich das Verhalten von \pgfintersectionofpathsnoch genauer untersuchte, stellte ich fest, dass es tatsächlich inkonsistent ist. Man würde erwarten, dass die folgenden Aufrufe von \pgfintersectionofpathsdasselbe Ergebnis liefern (1 Schnittpunkt, der Ursprung):
\pgfintersectionofpaths
{\pgfpathmoveto{\pgfpoint{0pt}{0pt}}\pgfpathlineto{\pgfpoint{1pt}{0pt}}}
{\pgfpathmoveto{\pgfpoint{0pt}{0pt}}\pgfpathlineto{\pgfpoint{0pt}{1pt}}}
\pgfintersectionsolutions
\pgfintersectionofpaths
{\pgfpathmoveto{\pgfpoint{0pt}{0pt}}\pgfpathlineto{\pgfpoint{1pt}{0pt}}}
{\pgfpathmoveto{\pgfpoint{0pt}{0pt}}\pgfpathlineto{\pgfpoint{-1pt}{0pt}}}
\pgfintersectionsolutions
Dies ist jedoch nicht der Fall: Die erste, bei der die Linien senkrecht zueinander sind, ergibt 1 Schnittpunkt, die andere, bei der die Linien (genau) parallel zueinander sind, ergibt 0 Schnittpunkte.
Ich würde das gern beheben, aber das Problem scheint mir zu komplex. Außerdem bin ich der Meinung, dass es eine Diskussion verdient und dass der Autor pgfbenachrichtigt werden sollte.
Antwort2
Ich bin nicht sicher, warum dies der Fall sein könnte, aber dieser Fehler scheint mit der verwendeten Schriftart zusammenzuhängen.
Ich kann Ihren Fehler reproduzieren, wenn ich Ihr MWE mit den folgenden Konfigurationen kompiliere:
- keine Font-Spezifikation (Computer/Latin Modern), kompiliert mit pdfLaTeX oder XeLaTeX
\usepackage{palatino}, kompiliert mit pdfLaTeX oder XeLaTeX\usepackage{libertine}, kompiliert mit pdfLaTeX oder XeLaTeX\usepackage{fontspec} \setmainfont{Linux Libertine O}, kompiliert mit XeLaTeX\usepackage{fontspec} \setmainfont{Doulos SIL}, kompiliert mit XeLaTeX\usepackage{fontspec} \setmainfont{TeX Gyre Pagella}, kompiliert mit XeLaTeX
Aber mit diesen Konfigurationen wird es ohne den Fehler kompiliert:
\usepackage{times}, kompiliert mit pdfLaTeX oder XeLaTeX\usepackage{kpfonts}, kompiliert mit pdfLaTeX oder XeLaTeX\usepackage{fontspec} \setmainfont{Charis SIL}, kompiliert mit XeLaTeX\usepackage{fontspec} \setmainfont{Cambria}, kompiliert mit XeLaTeX\usepackage{fontspec} \setmainfont{Brill}, kompiliert mit XeLaTeX\usepackage{fontspec} \setmainfont{Times New Roman}, kompiliert mit XeLaTeX
Bei diesem habe ich einen anderen Fehler erhalten (Dimension zu groß in der \end{forest}Zeile):
\usepackage{fontspec} \setmainfont{TeX Gyre Termes}, kompiliert mit XeLaTeX
Wenn Sie also die richtige Schriftart wählen, können Sie den Fehler vermeiden. Persönlich hätte ich aber trotzdem lieber eine Erklärung, wie man ihn unabhängig von der Schriftartauswahl vermeiden kann.