[Rd] boxplot() confuses x- and y-axes (PR#10345)
marc_schwartz at comcast.net
marc_schwartz at comcast.net
Mon Oct 15 21:05:18 CEST 2007
--=-ZyOtZFb05MaZLi4/Ovwu
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On Mon, 2007-10-15 at 18:25 +0200, maechler at stat.math.ethz.ch wrote:
> >>>>> "JO" == Jari Oksanen <jarioksa at sun3.oulu.fi>
> >>>>> on Mon, 15 Oct 2007 16:42:24 +0300 writes:
>
> JO> On Mon, 2007-10-15 at 15:25 +0200, maechler at stat.math.ethz.ch wrote:
> >> >>>>> "ms" == marc schwartz <marc_schwartz at comcast.net>
> >> >>>>> on Mon, 15 Oct 2007 14:20:16 +0200 (CEST) writes:
> >>
> ms> On Mon, 2007-10-15 at 10:30 +0200, bob.ohara at helsinki.fi wrote:
> >> >> Full_Name: Bob O'Hara
> >> >> Version: 2.6.0
> >> >> OS: Windows XP
> >> >> Submission from: (NULL) (88.112.20.250)
> >> >>
> >> >>
> >> >> Using horizontal=TRUE with boxplot() confuses it as to what is an x- or y-axis.
> >> >> At least, xlim= and ylim= are the wrong way round, log="x" (or "y") and xaxt=
> >> >> work as expected, I haven't looked at anything else.
> >> >>
> >> >> Some code to see if you can reproduce the bug (or discover it's in my head...):
> >> >>
> >> >> boxplot(count ~ spray, data = InsectSprays)
> >> >>
> >> >> # Try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, xlim=c(0,50))
> >> >>
> >> >> # Plot horizontally:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE)
> >> >>
> >> >> # Now try to change x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xlim=c(0,50))
> >> >> # Changes y-axis!
> >> >>
> >> >> # Now try to change y-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, ylim=c(0,50))
> >> >> # Changes x-axis!
> >> >>
> >> >> # Plot x-axis on log scale:
> >> >> boxplot(count+1 ~ spray, data = InsectSprays, horizontal=TRUE, log="x")
> >> >> # Does indeed change x-axis
> >> >>
> >> >> # Don't add ticks on x-axis:
> >> >> boxplot(count ~ spray, data = InsectSprays, horizontal=TRUE, xaxt="n")
> >> >> # Works as expected.
> >>
> ms> Hi Bob,
> >>
> ms> No, it's not in your head. This is documented in ?bxp, which is the
> ms> function that actually does the plotting for boxplot(). See the
> ms> description of 'pars' in ?bxp:
> >>
> ms> "Currently, yaxs and ylim are used â€ËÂœalong the boxplot’, i.e.,
> ms> vertically, when horizontal is false, and xlim horizontally."
> >>
> ms> So essentially, the named 'x' and 'y' axes are rotated 90 degrees when
> ms> you use 'horizontal = TRUE', rather than the vertical axis always being
> ms> 'y' and the horizontal axis always being 'x'. This has been discussed on
> ms> the lists previously.
> >>
> >> Yes; thank you, Marc.
> >>
> >> And the reason for this is very sensible I think:
> >>
> >> If you have a longish boxplot() or bxp() command,
> >> and you just want to go from vertical to horizontal or vice
> >> versa, it makes most sense just to have to change the
> >> 'horizontal' flag and not having to see if there are other 'x*'
> >> and or 'y*' arguments that all need to be changed as well.
> >>
> JO> Except that you must change xaxt/yaxt and log="x"/log="y" which do not
> JO> follow the "along the box" logic, and behave differently than
> JO> xlim/ylim.
>
> JO> Nothing of this is fatal, but this probably needs more than one
> JO> iteration to find which way each of the x* and y* arguments works.
>
> Oops!! Thank you Jari, for the note.
>
> What you describe is then very unfortunate, and I hadn't been
> aware of that.
>
> ``of course'', making any change to consistency
> would break existing code that consciously works with the
> current mis-"designed" behavior.
>
> But now I understand why we have the word "currently"
> in the description mentioned above.
>
> So given the help file, we should consider dropping the whole
> ``along the boxplot'' idea?
>
> {{well, yes, we should drop "traditional graphics" and work with
> grid-based graphical objects ("grob"s) that can be drawn
> vertically or horizontally,
> e.g., in lattice or (most probably) ggplot2
> }}
>
> Martin
The key code in question, from boxplot.R, seems to be:
if (!add) {
plot.new()
## shall we switch log for horizontal with
## switch(log, x="y", y="x", log) ??
if (horizontal)
plot.window(ylim = xlim, xlim = ylim, log = log, xaxs = pars$yaxs)
else
plot.window(xlim = xlim, ylim = ylim, log = log, yaxs = pars$yaxs)
}
xlog <- (par("ylog") && horizontal) || (par("xlog") && !horizontal)
So it would appear that ylim/xlim and xaxs/yaxs are interchanged when
horizontal = TRUE. All? other axis specific pars remain as per normal.
I have attached a proposed patch against bxp.Rd (against the current svn
copy) for consideration. Hopefully this makes ?bxp a bit more clear.
If any changes are to be made to current behavior, it would be good to
do this incrementally, with a note/warning added to 2.7.1 and then
changed in 2.8.0. If that is too soon, then increment by one version.
Thanks all,
Marc
--=-ZyOtZFb05MaZLi4/Ovwu
Content-Disposition: attachment; filename=diff.patch
Content-Type: text/x-patch; name=diff.patch; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
--- bxp.Rd 2007-10-15 13:27:21.000000000 -0500
+++ bxp.Rd.patch 2007-10-15 13:55:42.000000000 -0500
@@ -43,8 +43,8 @@
\item{frame.plot}{logical, indicating if a \sQuote{frame}
(\code{\link{box}}) should be drawn; defaults to \code{TRUE}, unless
\code{axes = FALSE} is specified.}
- \item{horizontal}{logical indicating if the boxplots should be
- horizontal; default \code{FALSE} means vertical boxes.}
+ \item{horizontal}{logical indicating if the boxplots should be
+ horizontal; default \code{FALSE} means vertical boxes. See note.}
\item{add}{logical, if true \emph{add} boxplot to current plot.}
\item{at}{numeric vector giving the locations where the boxplots
should be drawn, particularly when \code{add = TRUE}; defaults to
@@ -56,9 +56,6 @@
normally(\code{\dots}), see the following. (Those in \code{\dots}
take precedence over those in \code{pars}.)
- Currently, \code{yaxs} and \code{ylim} are used \sQuote{along the
- boxplot}, i.e., vertically, when \code{horizontal} is
- false, and \code{xlim} horizontally.
\code{xaxt}, \code{yaxt}, \code{las}, \code{cex.axis}, and
\code{col.axis} are passed to \code{\link{axis}}, and \code{main},
\code{cex.main}, \code{col.main}, \code{sub}, \code{cex.sub},
@@ -101,10 +98,15 @@
}%.../pars
}
\note{
- if \code{add = FALSE}, the default is \code{xlim = c(0.5, n +0.5)}.
+ If \code{add = FALSE}, the default is \code{xlim = c(0.5, n +0.5)}.
It will usually be a good idea to specify the latter if the "x" axis
has a log scale or \code{at} is specified or \code{width} is far from
uniform.
+
+ If \code{horizontal = TRUE}, the "y" axis is the horizontal axis and the "x"
+ axis is the vertical axis. Graphical pars \code{xlim/ylim} and
+ \code{xaxs/yaxs} are reversed in this case. Other axis related pars treat
+ the vertical axis as "y" and the horizontal axis as "x".
}
\value{
An invisible vector, actually identical to the \code{at} argument,
--=-ZyOtZFb05MaZLi4/Ovwu--
More information about the R-devel
mailing list