[Rd] boxplot() confuses x- and y-axes (PR#10345)

[maechler at stat.math.ethz.ch]

>>>>> "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