[Rd] boxplot and bxp do not respect xlim by default (PR#9754)

[ripley at stats.ox.ac.uk]

Note that ?bxp quite carefully says which graphical pars it does and does 
not accept, and 'xlim' is one it does not accept.  So this is a wish, not 
a bug.

The easy part is to allow it to accept 'xlim' is specified.  The harder 
part is to find a good default of xlim in general.  Steve's suggestion is 
not good if the boxes differ in size or if at = c(0, 10:15), for example.
It seems to me that 'at' would normally be used with add=T, so I don't 
think we need to do this well (and the user will always be able to set 
'xlim').


I am about to commit an improved version for R-devel.

On Tue, 26 Jun 2007, murdoch at stats.uwo.ca wrote:

> On 6/26/2007 8:16 AM, s.ellison at lgc.co.uk wrote:
>> Full_Name: Steve Ellison
>> Version: 2.4.1
>> OS: Windows, Linux
>> Submission from: (NULL) (194.73.101.157)
>>
>>
>> bxp() allows specifcation of box locations with at=, but neither adjusts xlim=
>> to fit at nor does it respect xlim provided explicitly.
>>
>> This is because bxp() now includes explicit xlim as c(0.5, n+0.5), without
>> checking for explicitly supplied xlim (or ylim if horizontal).
>>
>> This also prevents simple added plots (eg if add=T, with at=(1:n)+0.5, the last
>> box is partly off the plot.
>>
>> The 'offending' code is in bxp:
>>     if (!add) {
>>         plot.new()
>>         if (horizontal)
>>             plot.window(ylim = c(0.5, n + 0.5), xlim = ylim,
>>                 log = log, xaxs = pars$yaxs)
>>         else plot.window(xlim = c(0.5, n + 0.5), ylim = ylim,
>>             log = log, yaxs = pars$yaxs)
>>     }
>>
>> Suggested fix:
>>    if (!add) {
>>         plot.new()
>> 	bxp.limits <- if(!is.null(at)) {
>>               c(at[1]-(at[2]-at[1])/2, at[n]+(at[n]-at[n-1])/2 )
>>            } else {
>>               c(0.5, n + 0.5)
>>            }
>>         if (horizontal)
>>             plot.window(ylim = if(is.null(pars$xlim)) bxp.limits else
>> pars$xlim,
>>                       xlim = ylim, log = log, xaxs = pars$yaxs)
>>         else plot.window(xlim = if(is.null(pars$xlim)) bxp.limits else
>> pars$xlim,
>>                       ylim = ylim, log = log, yaxs = pars$yaxs)
>>     }
>>
>>
>> This retains the current defaults for xlim with at unspecified but allows
>> explicit specification of xlim. (which is the grouping level axis whether
>> horizontal or vertical).
>
> But it fails in a few other cases:  if the user sets the widths, this
> doesn't respect that setting; if the user specifies the location of one
> boxplot (so length(at) == 1) it fails when it tries to access at[2].
>
> This is a somewhat tricky problem, that needs more careful thought than
> I have time for right now, so I'll leave it for someone else (or for
> myself in a less busy future, which may exist in some alternate universe).
>
> What I'd suggest you do in the short term is simply to set up the plot
> axes the way you want before calling bxp, then call it with add=TRUE.
>
> Duncan Murdoch
>
>>
>> I've tested the above as far as producing a modified bxp and plotting a boxplot
>> object, but have not tried calling direct from boxplot. boxplot() should,
>> however, not need modification as xlim and ylim are, I believe, passed via the
>> namedargs list in the bxp call.
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595