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

______________________________________________
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.

Reply via email to