4

When using pgfplots to plot certain values, my axis labels "get stuck" at one side of the axis (see the lower right corner of the image below).

The original plot contained many more data points which made it even more ugly.

I have reduced this to these three numbers:

\documentclass{article}

\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=1.10}

\begin{document}

\begin{tikzpicture}
\begin{axis}
\addplot coordinates { (-323573.5, -327215.79) (-323572.1, -327210.13) (-323572.1, -327206.85) };
\end{axis}
\end{tikzpicture}

\end{document}

enter image description here

  • Welcome to TeX.SX! That is an interesting issue you have come across here. I can reproduce the issue and (un)surprisingly everything is fine if you switch the signs of the points. – moewe Sep 9 '15 at 9:47
  • Reproduced in 1.12 with \addplot coordinates { (-4, -4) }; It is not about the signs. \addplot coordinates { (4, 3) }; works (does not work) as well. – LaRiFaRi Sep 9 '15 at 12:11
  • Thanks for your reproductions! I take that this is not my inability to use the software, but a bug? Then I would report it. Can you think of a workaround? This (but bigger) is basically the last figure of my thesis :) – marc Sep 9 '15 at 15:48
  • @marc Yes I would report this to Christian Feuersänger. For you to finish that plot: Just add \addplot[draw=white] coordinates {(-323570,-327210)}; as last line in your axis. You might need to play around with that values until it fits for your actual graph. I hope, you are printing on white background, though... – LaRiFaRi Sep 10 '15 at 8:01
  • Another possibility (also no beautiful) would be \begin{axis}[xmin=-323574,xmax=-323570]. When playing around with those values, you will notice that pgfplots is having trouble with calculating with that big values. The axis has to be split into equal parts and this seems to fail for some numbers. Sometimes I even get a dimension too large error which is not coming from the number it self but from some algorithm happening behind the scene. – LaRiFaRi Sep 10 '15 at 8:09
2

What happens here is that pgfplots looses a huge amount of precision: it "zooms" into the data range x=[-323573.5:-323572.1]. this "zoom into" means to compute max-min, and this means that almost all digits of the computation are lost ("cancellation"). this is particularly bad since at least parts of this computation is carried out in in TeX, and its relative precision (i.e. the number of available digits) is too small for this data range.

The solution would be to use a tool with higher precision in order to transform the data range, then let TeX compute the plot and remap the tick labels lateron. The steps "transform", "compute", "remap" is typically done by pgfplots on its own, but it cannot due to its limited precision.

In fact, we could try to configure the necessary "transform" step in TeX, but I fear it would loose so much precision that it is unclear if the descriptions would be correct.

I hacked around with a lua prototype which uses lua's math engine (the lua backend shipped with pgfplots 1.12). It appears to work:

\documentclass{standalone}

\usepackage{tikz}
\usepackage{pgfplots}
\pgfplotsset{compat=1.12}

\begin{document}

\begin{tikzpicture}
\begin{axis}[
    xticklabel style={rotate=45,anchor=east},
    xticklabel={\pgfluamathparse{1e-5*(\tick-323573)}\pgfmathprintnumber[precision=6]\pgfmathresult},
    yticklabel={\pgfluamathparse{1e-5*(\tick-327215)}\pgfmathprintnumber[precision=6]\pgfmathresult},
    scaled x ticks=manual:{$\cdot 10^5$}{\def\pgfmathresult{#1}},
    scaled y ticks=manual:{$\cdot 10^5$}{\def\pgfmathresult{#1}},
]
\addplot+[
    x filter/.expression={x+323573},
    y filter/.expression={y+327215},
]coordinates { (-323573.5, -327215.79) (-323572.1, -327210.13) 
(-323572.1, -327206.85) };
\end{axis}
\end{tikzpicture}

\end{document}

enter image description here

This solution shows that your application is beyond the limits of pgfplots: I added manual code for

  • coordinate transformation (the x filter/.expression is supported by the lua backend, so this is carried out in lua double precision)
  • inverse transformation for the tick labels. I used \pgfluamathparse which is part of the lua backend (undocumented currently) since I believe that the fpu shipped with pgfplots cannot compute this with reasonable accuracy.
  • tick scaling: I added a tick scale label to document the factor 1e-5 in the tick label display

This solution currently lacks support for xtick, though: you would need to provide xtick in terms of the transformed coordinates.

You can try to make use of this prototype. Maybe you want to map your data manually before you include it in pgfplots.

| improve this answer | |

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.