R devel - Jun 2007 - boxplot and bxp do not respect xlim by default (PR#9754)

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 xlimto
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).

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.

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)
That version is obsolete, but this problem is still present in R-devel. 
  I'll take a look.

Duncan Murdoch
> 
> 
> 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).
> 
> 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

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

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

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