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

[S Ellison]

Brian,

> Note that ?bxp quite carefully says which graphical pars it does and does
> not accept, and 'xlim' is one it does not accept.  
In my version at the time, bxp did not list which plot parameters it does not accept. xlim was simply not mentioned at all. I can't easily see lack of a mention as _good_ documentation of lack of acceptance when other unmentioned parameters ARE accepted and when plot.default is very clear on xlim being an allowed parameter by default. But that's pretty much academic if one adds xlim support in bxp.

> Steve's suggestion is
> not good if the boxes differ in size or if at = c(0, 10:15) [or if unordered at]
Certainly true (and I was kicking myself only shortly after posting it for exactly the same reason!). 
But the default for xlim stays much simpler if brian's next point is accepted:

>I should have added that some code assumes the current default for xlim 
>even when 'at' is specified, including the last example in boxplot.
An important point. That says one should not change the default xlim to adjust for arbitrary at. Fortunately, that makes life easier: keep the present xlim defaults while allowing allow user-specified xlim is near-trivial compared to implementing a general at-specific xlim default. 

>...and when there is a log x axis (and there the previous default is 
>also inadequate).
The log issue, ironically, perhaps IS a bug, as log is an allowed parameter on the x-axis (via log="x") and width is chosen without paying it any attention. I haven't looked closely at a required code mod, but it's adjustable with user-specified boxwex. Perhaps documenting the fact of a poor default and suggesting manual boxwex might be sufficient remedy? 

If I understand the discussion so far, though, the "requirement" for this bugfix/wishfix would go something like this:

i) if at is unspecified, at=1:n; if specified, it is respected. (true now)

ii) if xlim is unspecified, xlim=c(0.5,  n+0.5); if it is specified, it is respected for add=F. (only adds respect for specified xlim)

iii) For add=T, xlim should be ignored if specified (silently? with warning?). (Currently silently ignored)

iv) behaviour on log="x" should be noted in the help.

The above are fairly trivial to implement and document, as such things go... I'd be happy to give it a shot.


Steve Ellison
 


>>> Prof Brian Ripley <ripley at stats.ox.ac.uk> 02/07/2007 15:15:16 >>>
On Mon, 2 Jul 2007, ripley at stats.ox.ac.uk wrote:

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. , 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 should have added that some code assumes the current default for xlim 
even when 'at' is specified, including the last example in boxplot.

Other cases where Steve's suggestion was wrong are when 'at' is not 
sorted, and when there is a log x axis (and there the previous default is 
also inadequate).


>
>
> 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
*******************************************************************
This email and any attachments are confidential. Any use, co...{{dropped}}