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, [EMAIL PROTECTED] wrote:
> On 6/26/2007 8:16 AM, [EMAIL PROTECTED] 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@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Brian D. Ripley, [EMAIL PROTECTED]
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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
