Bugzilla – Bug 14833
Using 'axis' overshoots lower plotting region limit for logged plots
Last modified: 2012-03-18 11:14:53 UTC
When plotting a logged axis plot and using 'axis' to add an additional axis with manual tick mark locations, the lower boundary overshoots the plotting region.
> plot(tan, xlim=c(1e5, 1e12), log="x")
> axis(side=3, at=c(1e4, 1e100))
As you can see when plotting the above example, the lower axis overshoots the plotting area whilst the upper limit, despite a very large 'at' value, is automatically clipped at the upper limit of the plotting region.
I would naively expect the lower axis to be clipped at the lower limit of the plotting region in a similar manner to the upper limit. The fact that it does not is somewhat inconsistent in how axis handles the lower and upper limits.
This bug does not appear if the relative range of xlim is smaller.
I have the need to specify 'axis' ranges outside the plotting region as it allows me to trivially have minor tick marks trailing all the way to the edge of the plot. These minor axes then replace the need for the use of 'box' to create an enclosed plotting region. If left unfixed, this bug would limit my options in this regard to either an overshot axis, or a plotting region with a gap in its bounding box.
I have tested this on a Mac OSX system, only to find the same issue reappearing.
I hope I have provided enough explanation both of the bug and my need for specifying unusually large axis limits outside of the range of the plotting region. Even if not, there is currently an inconsistency here within R regards the handling of the lower and upper limits.
Thank you in advance,
The problem was that the axes were calculated to be a fraction epsilon outside the range of the user coordinates, where epsilon is about 2 e-16. But when your axis range is about 1e12, that's a sizeable number, and it ended up with the lower limit around -50000 in your example.
I'll fix it and commit shortly.
Sorry, wrong epsilon -- the one used here is the single precision one.
Thank you very much for fixing this!
It has frustrated me for some time, much appreciated.
(In reply to comment #2)
> Sorry, wrong epsilon -- the one used here is the single precision one.