Markings fail with "Dimension too Large" on certain paths

[pgf-tikz-bot]

Migrated from SourceForge
Author: akissinger
Timestamp: 2012-03-01 15:18:28

When I try to place a marking on a curved edge, pdflatex dies with message:

! Dimension too large.

\relax
l.57 ...ow{>}}, in=72, out=-90] (1.center) to (0);

! ==> Fatal error occurred, no output PDF file produced!

This seems to happen when the marking should be placed on a totally vertical piece of the curve. Here is an example:

\begin{tikzpicture}
\node [minimum height=6mm] (0) at (0, 0) {};
\node [inner sep=0mm] (1) at (0.25, 1.25) {};
\draw [
    postaction=decorate,
    decoration={
        markings, 
        mark=at position 0.55 with \arrow{>},
    }, 
    in=72, 
    out=-90,
] (1.center) to (0);
\end{tikzpicture}

Setting in=-90.1 causes the bug not to occur. This happens both in the latest CVS, and the version of PGF/TikZ bundled with Texlive 2011.

[pgf-tikz-bot]

Migrated from SourceForge
Author: tantau
Timestamp: 2013-07-18 13:14:32.290000

• status: open --> closed-fixed
• Group: --> v1.0 (example)

[pgf-tikz-bot]

Migrated from SourceForge
Author: tantau
Timestamp: 2013-07-18 13:14:33.175000

Fixed in CVS.

[ghost]

The fix is overall great! However, just for the records: these issues are not completely fixed, one can still get dimension too large errors. Some of them disappear if one replaces \pgfmathreciprocal@ by some fpu variant. I strongly suspect more issues get resolved by installing an fpu version of \pgftransforminvert. True, fpu slows down the computation a bit, but still it might be worthwhile to offer some switches of that sort to the users.

[hmenke]

There is the added performance penalty, but on top when using the fpu you only replacing one class of problems (Dimension too large) with a different one (Massive rounding errors, see e.g. #734). This owes to the fact that the fpu is not actually a floating-point unit, despite the name. It does not implement floating-point arithmetic, but merely rescales the arguments to functions to avoid overflows. That pretty much sums it up why I won't add fpu variants for drawing operations.

[ghost]

@hmenke I do not think your statement is generally true. For instance, in https://tex.stackexchange.com/q/529099/194703 switching to fpu precisely corrected the rounding errors. I agree, of course, that fpu is not perfect (in particular when it comes to dealing with integers) but there are many cases in which it saves the day. And of course one could also allow the user to switch on other things like xfp when doing these things. Most importantly, there appear to be more than enough situation in which switching on fpu does not replace one problem by another problem but just fixes the problem, e.g. https://tex.stackexchange.com/q/497399/194703. It appears to be too much to ask that some fix is perfect, it might be sufficient to cure a large subset of the problems.