Bug 10345 - boxplot() confuses x- and y-axes
Summary: boxplot() confuses x- and y-axes
Status: NEW
Alias: None
Product: R
Classification: Unclassified
Component: Wishlist (show other bugs)
Version: old
Hardware: ix86 (32-bit) Windows 32-bit
: P5 normal
Assignee: Jitterbug compatibility account
URL:
Depends on:
Blocks:
 
Reported: 2007-10-15 13:25 UTC by Jitterbug compatibility account
Modified: 2007-10-15 21:24 UTC (History)
0 users

See Also:


Attachments
(1.95 KB, text/x-patch)
2007-10-16 00:01 UTC, Jitterbug compatibility account
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jitterbug compatibility account 2007-10-15 13:25:36 UTC
From: bob.ohara@helsinki.fi
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.

Comment 1 Jitterbug compatibility account 2007-10-15 17:18:23 UTC
From: Marc Schwartz <marc_schwartz@comcast.net>
On Mon, 2007-10-15 at 10:30 +0200, bob.ohara@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.

Hi Bob,

No, it's not in your head. This is documented in ?bxp, which is the
function that actually does the plotting for boxplot(). See the
description of 'pars' in ?bxp:

"Currently, yaxs and ylim are used ‘along the boxplot’, i.e.,
vertically, when horizontal is false, and xlim horizontally."

So essentially, the named 'x' and 'y' axes are rotated 90 degrees when
you use 'horizontal = TRUE', rather than the vertical axis always being
'y' and the horizontal axis always being 'x'. This has been discussed on
the lists previously.

Regards,

Marc Schwartz


Comment 2 Jitterbug compatibility account 2007-10-15 18:21:51 UTC
From: Martin Maechler <maechler@stat.math.ethz.ch>
>>>>> "ms" == marc schwartz <marc_schwartz@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@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.

Regards,
Martin Maechler

Comment 3 Jitterbug compatibility account 2007-10-15 18:42:24 UTC
From: Jari Oksanen <jarioksa@sun3.oulu.fi>
On Mon, 2007-10-15 at 15:25 +0200, maechler@stat.math.ethz.ch wrote:
> >>>>> "ms" == marc schwartz <marc_schwartz@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@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.
> 
Except that you must change xaxt/yaxt and log="x"/log="y" which do not
follow the "along the box" logic, and behave differently than
xlim/ylim. 

Nothing of this is fatal, but this probably needs more than one
iteration to find which way each of the x* and y* arguments works.

cheers, jari oksanen

Comment 4 Jitterbug compatibility account 2007-10-15 21:24:47 UTC
From: Martin Maechler <maechler@stat.math.ethz.ch>
>>>>> "JO" == Jari Oksanen <jarioksa@sun3.oulu.fi>
>>>>>     on Mon, 15 Oct 2007 16:42:24 +0300 writes:

    JO> On Mon, 2007-10-15 at 15:25 +0200, maechler@stat.math.ethz.ch wrote:
    >> >>>>> "ms" == marc schwartz <marc_schwartz@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@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

Comment 5 Jitterbug compatibility account 2007-10-16 00:01:22 UTC
From: Marc Schwartz <marc_schwartz@comcast.net>
PARTS: 2
On Mon, 2007-10-15 at 18:25 +0200, maechler@stat.math.ethz.ch wrote: 
> >>>>> "JO" == Jari Oksanen <jarioksa@sun3.oulu.fi>
> >>>>>     on Mon, 15 Oct 2007 16:42:24 +0300 writes:
> 
>     JO> On Mon, 2007-10-15 at 15:25 +0200, maechler@stat.math.ethz.ch wrote:
>     >> >>>>> "ms" == marc schwartz <marc_schwartz@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@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


(Attached 'diff.patch' of type 'text/x-patch')

**END
Comment 6 Jitterbug compatibility account 2007-10-16 00:01:22 UTC
Created attachment 1071 [details]
Comment 7 Jitterbug compatibility account 2007-10-16 00:34:41 UTC
From: "hadley wickham" <h.wickham@gmail.com>
> 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
> }}

ggplot2 does this in a completely general way (i.e. for all types of
graphics) with the coord_flip coordinate system, which flips the
interpretation of the x and y scales.  This includes producing
smoothers of x conditional on y, and so forth.

Hadley

-- 
http://had.co.nz/

Comment 8 Jitterbug compatibility account 2008-12-15 22:56:00 UTC
NOTES:
 as docuemnted, if not ideal
Comment 9 Jitterbug compatibility account 2008-12-15 22:59:03 UTC
Audit (from Jitterbug):
Tue Oct 16 13:47:05 2007	ripley	moved from incoming to Graphics
Mon Dec 15 17:59:03 2008	ripley	changed notes
Mon Dec 15 16:59:03 2008	ripley	moved from Graphics to wishlist