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 <[EMAIL PROTECTED]> wrote: > Hi > > > Gabor Grothendieck wrote: > > On 6/7/05, Paul Murrell <[EMAIL PROTECTED]> wrote: > > > >>Hi > >> > >> > >>Gabor Grothendieck wrote: > >> > >>>On 6/6/05, Paul Murrell <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>>>Hi > >>>> > >>>> > >>>>Gabor Grothendieck wrote: > >>>> > >>>> > >>>>>On 6/2/05, Paul Murrell <[EMAIL PROTECTED]> 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 > >>>>[EMAIL PROTECTED] > >>>>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 > >>[EMAIL PROTECTED] > >>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 > [EMAIL PROTECTED] > http://www.stat.auckland.ac.nz/~paul/ > > ______________________________________________ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel