Suppose ri were already defined as in the example below. Then panel.qrect is a bit harder to define although with work its possible as shown below:
rectInfo <- list(matrix(runif(4), 2, 2), matrix(runif(4), 2, 2), matrix(runif(4), 2, 2)) ri <- function(x, y, ..., rect.info) { ri <- rect.info[[packet.number()]] panel.rect(ri[1, 1], ri[1, 2], ri[2, 1], ri[2, 2], col = "grey86", border = NA) panel.xyplot(x, y, ...) } panel.qrect <- function(rect.info) { function(x, y, ...) { environment(ri) <- environment() ### ri(x, y, ..., rect.info = rect.info) } } xyplot(runif(30) ~ runif(30) | gl(3, 10), panel = panel.qrect(rectInfo)) On 7/14/07, Stephen Tucker <[EMAIL PROTECTED]> wrote: > This is very interesting - but I'm not entirely clear on your last statement > though about how existing functions can cause problems with the scoping that > createWrapper() avoids... (but thanks for the tip). > > > --- Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > > > Your approach of using closures is cleaner than that > > given below but just for comparison in: > > > > http://tolstoy.newcastle.edu.au/R/devel/06/03/4476.html > > > > there is a createWrapper function which creates a new function based > > on the function passed as its first argument by using the components > > of the list passed as its second argument to overwrite its formal > > arguments. For example, > > > > createWrapper <- function(FUN, Params) { > > as.function(c(replace(formals(FUN), names(Params), Params), body(FUN))) > > } > > > > library(lattice) > > > > rectInfo <- > > list(matrix(runif(4), 2, 2), > > matrix(runif(4), 2, 2), > > matrix(runif(4), 2, 2)) > > > > > > panel.qrect <- function(x, y, ..., rect.info) { > > ri <- rect.info[[packet.number()]] > > panel.rect(ri[1, 1], ri[1, 2], ri[2, 1], ri[2, 2], > > col = "grey86", border = NA) > > panel.xyplot(x, y, ...) > > } > > > > xyplot(runif(30) ~ runif(30) | gl(3, 10), > > panel = createWrapper(panel.qrect, list(rect.info = rectInfo))) > > > > The createWrapper approach does have an advantage in the situation > > where the function analogous to panel.qrect is existing since using > > scoping then involves manipulation of environments in the closure > > approach. > > > > On 7/11/07, Stephen Tucker <[EMAIL PROTECTED]> wrote: > > > In the Trellis approach, another way (I like) to deal with multiple > > pieces of > > > external data sources is to 'attach' them to panel functions through > > lexical > > > closures. For instance... > > > > > > rectInfo <- > > > list(matrix(runif(4), 2, 2), > > > matrix(runif(4), 2, 2), > > > matrix(runif(4), 2, 2)) > > > > > > panel.qrect <- function(rect.info) { > > > function(x, y, ...) { > > > ri <- rect.info[[packet.number()]] > > > panel.rect(ri[1, 1], ri[1, 2], ri[2, 1], ri[2, 2], > > > col = "grey86", border = NA) > > > panel.xyplot(x, y, ...) > > > } > > > } > > > > > > xyplot(runif(30) ~ runif(30) | gl(3, 10), > > > panel = panel.qrect(rectInfo)) > > > > > > ...which may or may not be more convenient than passing rectInfo (and > > perhaps > > > other objects if desired) explicitly as an argument to xyplot(). > > > > > > > > > --- Deepayan Sarkar <[EMAIL PROTECTED]> wrote: > > > > > > > On 7/11/07, hadley wickham <[EMAIL PROTECTED]> wrote: > > > > > > A question/comment: I have usually found that the subscripts > > argument > > > > is > > > > > > what I need when passing *external* information into the panel > > > > function, for > > > > > > example, when I wish to add results from a fit done external to the > > > > trellis > > > > > > call. Fits[subscripts] gives me the fits (or whatever) I want to > > plot > > > > for > > > > > > each panel. It is not clear to me how the panel layout information > > from > > > > > > panel.number(), etc. would be helpful here instead. Am I correct? > > -- or > > > > is > > > > > > there a smarter way to do this that I've missed? > > > > > > > > > > This is one of things that I think ggplot does better - it's much > > > > > easier to plot multiple data sources. I don't have many examples of > > > > > this yet, but the final example on > > > > > http://had.co.nz/ggplot2/geom_abline.html illustrates the basic idea. > > > > > > > > That's probably true. The Trellis approach is to define a plot by > > > > "data source" + "type of plot", whereas the ggplot approach (if I > > > > understand correctly) is to create a specification for the display > > > > (incrementally?) and then render it. Since the specification can be > > > > very general, the approach is very flexible. The downside is that you > > > > need to learn the language. > > > > > > > > On a philosophical note, I think the apparent limitations of Trellis > > > > in some (not all) cases is just due to the artificial importance given > > > > to data frames as the one true container for data. Now that we have > > > > proper multiple dispatch in S4, we can write methods that behave like > > > > traditional Trellis calls but work with more complex data structures. > > > > We have tried this in one bioconductor package (flowViz) with > > > > encouraging results. > > > > > > > > -Deepayan > > > > > > > > ______________________________________________ > > > > R-help@stat.math.ethz.ch mailing list > > > > https://stat.ethz.ch/mailman/listinfo/r-help > > > > PLEASE do read the posting guide > > > > http://www.R-project.org/posting-guide.html > > > > and provide commented, minimal, self-contained, reproducible code. > > > > > > > > > > ______________________________________________ > > > R-help@stat.math.ethz.ch mailing list > > > https://stat.ethz.ch/mailman/listinfo/r-help > > > PLEASE do read the posting guide > > http://www.R-project.org/posting-guide.html > > > and provide commented, minimal, self-contained, reproducible code. > > > > > > > > > > ____________________________________________________________________________________ > > that gives answers, not web links. > > ______________________________________________ > R-help@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. > ______________________________________________ R-help@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.