Re: [Rd] Re: [R] Problem going back to a viewport with gridBase

From: Gabor Grothendieck <ggrothendieck_at_gmail.com>
Date: Wed 08 Jun 2005 - 02:02:09 GMT

Yes, I understand that although such order is convenient for the user as the significant reduction in code size here shows. I wonder if there might be some performance parameter (e.g. hash) to control it. If hash = TRUE then no guarantee is provided. Otherwise order is kept.

On 6/7/05, Paul Murrell <p.murrell@auckland.ac.nz> wrote:
> Hi
>
>
> Gabor Grothendieck wrote:
> > On 6/7/05, Paul Murrell <p.murrell@auckland.ac.nz> wrote:
> >
> >>Hi
> >>
> >>
> >>Gabor Grothendieck wrote:
> >>
> >>>On 6/6/05, Paul Murrell <p.murrell@auckland.ac.nz> wrote:
> >>>
> >>>
> >>>>Hi
> >>>>
> >>>>
> >>>>Gabor Grothendieck wrote:
> >>>>
> >>>>
> >>>>>On 6/2/05, Paul Murrell <p.murrell@auckland.ac.nz> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Hi
> >>>>>
> >>>>>
> >>>>>Thanks. I have mucked around in vpTree structures and discovered its
> >>>>>actually quite easy to specify children so I have changed my example
> >>>>>so that instead of naming the children of 'layout' and then remembering
> >>>>>coordinates linked to the names of the children of 'layout' in
> >>>>>the 'coords' structure (which really just duplicates state information
> >>>>>already available in grid) it simply follows the order
> >>>>>of the children of 'layout' directly. This permits elimination of 'coords'
> >>>>>and the two naming functions. Using the depth approach you advocate,
> >>>>>'with' also becomes shorter and I think I have it to the point where it works
> >>>>>with both vpPath and viewport classes. Once Deepayan implements
> >>>>>the use.viewport= argument to print, 'with' can be eliminated too. No
> >>>>>questions this time but I thought I would post the latest version for
> >>>>>completeness. Regards.
> >>>>
> >>>>
> >>>>Ok. I can see this working ... for now. The disadvantage with this
> >>>>approach is that it makes use of the undocumented, internal structure of
> >>>>a viewport tree to grab a list of child viewports. A worse example of
> >>>>the same thing is that the with() methods make use of a happy
> >>>>coincidence that both viewport objects and viewport path objects share a
> >>>>component called "name" (and an even happier coincidence that they
> >>>>contain the same information). I think it would be cleaner and better
> >>>>practice, despite requiring longer code, to make use of the documented
> >>>>interface which requires specifying viewport names and viewport paths.
> >>>>The internal structure of objects is not guaranteed to be stable.
> >>>
> >>>
> >>>Perhaps accessor functions could be provided that allow one to
> >>>retrieve the name of a viewport and the name of a vpPath in
> >>>a safe way. These could be as simple as:
> >>>
> >>>names.viewport <- names.vpPath <- function(x) x$name
> >>
> >>
> >>Fair enough. If I say "use the API", I should provide a useful API :)
> >>
> >>This is a reasonable request for viewports; the "name" component of a
> >>viewport is a sensible thing to want.
> >>
> >>OTOH, it is not necessarily reasonable for a viewport path; not all
> >>components of an object should necessarily have accessors. The "name"
> >>component of a viewport path is the last element in the path. Perhaps
> >>an API should be supplied for extracting parts of a viewport path, but
> >>it should probably be something along the lines of car()/cdr() or
> >>head()/tail() or explode() to get different bits of the path.
> >>
> >>Accessing the children of a viewport is subtly problematic too.
> >>Directly accessing the "children" slot and using the order of the
> >>children in that slot is "dangerous" because there is no claim made by
> >>the system as to how the children are internally ordered. Again, it
> >>works currently, but it makes incorrect assumptions about what the
> >>system is doing internally so is vulnerable to future changes.
> >
> >
> > That is the point of an accessor. If the internals change then the
> > accessor is modified to hide the change so that the user using the
> > accessor is not impacted.
> >
> > It seems that grid already partly supports this with the childNames
> > function. It could be made generic and a method provided
> > to cover the classes discussed here too.
>
>
> I agree that a childNames() method for a viewport tree is probably
> reasonable. The subtle problem is the fact that your code makes use of
> the *order* of the names that function would return, when in fact there
> is no claim that they will be in any particular order.
>
> Paul
>
>
> >>So again, the recommended approach is to use the API provided; you
> >>provide the naming scheme for viewports and you control the order in
> >>which viewports are used.
> >>
> >>Paul
> >>
> >>
> >>
> >>>Similarly an accessor function to safely retrieve the children would
> >>>be nice. Again, it should ideally be possible to
> >>>have a generic with methods for various grid classes.
> >>>
> >>>Then the relevant line in the code concerning name
> >>>could be written in a safe way like this:
> >>>
> >>>depth <- if (data$name == "ROOT") 0 else downViewport(names(data))
> >>>
> >>>and similarly for the children.
> >>>
> >>>
> >>>
> >>>
> >>>>Paul
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>[pushLayout is same as before except there are no names on the
> >>>>>children of 'layout' and the rest is new]
> >>>>>
> >>>>>library(grid)
> >>>>>library(lattice)
> >>>>>
> >>>>>pushLayout <- function(nr, nc, name="layout") {
> >>>>> pushViewport(viewport(layout=grid.layout(nr, nc), name=name))
> >>>>> for (i in 1:nr) {
> >>>>> for (j in 1:nc) {
> >>>>> pushViewport(viewport(layout.pos.row=i, layout.pos.col=j))
> >>>>> upViewport()
> >>>>> }
> >>>>> }
> >>>>> upViewport()
> >>>>>}
> >>>>>
> >>>>>with.vpPath <- with.viewport <- function(data, expr, ...) {
> >>>>> # if data is a vpPath it cannot be ROOT since NULL will never
> >>>>>dispatch here
> >>>>> depth <- if (data$name == "ROOT") 0 else downViewport(data$name)
> >>>>> result <- eval.parent(substitute(expr))
> >>>>> upViewport(depth)
> >>>>> invisible(result)
> >>>>>}
> >>>>>
> >>>>>grid.newpage()
> >>>>>
> >>>>># specify number of cells to fill and number of rows
> >>>>>n <- 5; nr <- 3
> >>>>>
> >>>>>nc <- ceiling(n/nr)
> >>>>>downViewport(pushLayout(nr, nc))
> >>>>>
> >>>>>vpt <- current.vpTree(all = FALSE)
> >>>>>for(k in 1:n) with(vpt$children[[k]],
> >>>>> print( xyplot(v ~ v, list(v = 1:k)), newpage = FALSE )
> >>>>>)
> >>>>
> >>>>
> >>>>--
> >>>>Dr Paul Murrell
> >>>>Department of Statistics
> >>>>The University of Auckland
> >>>>Private Bag 92019
> >>>>Auckland
> >>>>New Zealand
> >>>>64 9 3737599 x85392
> >>>>paul@stat.auckland.ac.nz
> >>>>http://www.stat.auckland.ac.nz/~paul/
> >>>>
> >>>
> >>
> >>--
> >>Dr Paul Murrell
> >>Department of Statistics
> >>The University of Auckland
> >>Private Bag 92019
> >>Auckland
> >>New Zealand
> >>64 9 3737599 x85392
> >>paul@stat.auckland.ac.nz
> >>http://www.stat.auckland.ac.nz/~paul/
> >>
> >
> >>
>
>
> --
> Dr Paul Murrell
> Department of Statistics
> The University of Auckland
> Private Bag 92019
> Auckland
> New Zealand
> 64 9 3737599 x85392
> paul@stat.auckland.ac.nz
> http://www.stat.auckland.ac.nz/~paul/
>
>



R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel Received on Wed Jun 08 12:06:10 2005

This archive was generated by hypermail 2.1.8 : Mon 20 Feb 2006 - 03:21:08 GMT