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
