On Mon, 2 Jul 2007, [EMAIL PROTECTED] wrote: > 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 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, [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