[Phylobase-devl] What I did with my summer vacation -- phylobase plotting

[Peter Cowan]

On Fri, Aug 8, 2008 at 2:33 AM, Thibaut Jombart
<jombart at biomserv.univ-lyon1.fr> wrote:
> Peter Cowan wrote:
>>
> Here are a few comments or issues. It seems important to me to specify the
> size taken by the phylogeny (like the 'ratio' argument in former version). I
> am sure your function can implement that easily, but I did not find it from
> the arguments (I just looked at the arguments of treePlot). This would be
> especially valuable since some new functionalities for plotting data are
> awesome, but would require some more space (treePlot(geospiza, tip.plot.fun
> = 'density') is terrific!). BTW, it would be nice to have documentation for
> your new functions.

Tibaut, you're right there aren't any arguments for setting the plot
region (margins or ratio), I will add those at some point. The bubble
plot, at least, should offer a way to adjust this parameter. Right now
it tries to be smart about partitioning space, in the case of the
'density' plot, the top and bottom edges of those plots are adjacent,
if they were made any larger they would overlap.

> Playing with treePlot, I found some issues:
> #### error
>> treePlot(geospiza, type="cladogram")
> Error in xxyy$xx[phy at edge[, 2] <= Ntips] <- 1 : object "xxyy" not found

Thanks for this, I've fixed it in my files.  A silly attempt to neaten
code on my part.  Note, that this argument probably won't provide
useful output.  e.g. treePlot(as(rtree(100), 'phylo4'), type =
'cladogram'), and I might just remove it.

> #### this one works, but data are not rotated
>> treePlot(geospiza, tip.plot.fun = ff, rot=90)

Thanks, I think this is fixed now.

> ####
> Argument show.tip.labels: it would be nice to have a vector of two logical,
> so that we could choose to represent tip.labels two times, once, or not at
> all (not at all is not possible currently).

Agreed, how would you feel about passing an argument to phylobubbles
dictating x and y labels, e.g. labels = c('x', 'y', 'both', TRUE,
FALSE).  I think might be slightly clearer, but I'm open to other
opinions.

> ####
> Re-implementation of former plotting would require a legend for the symbols.
> Arguments for centring/scaling should be available, and I think data
> transformations should not be made inside phylobubbles.

Agreed, the legend is on my todo list.  I agree with you regarding the
transformations, I was simply trying to match the default output from
your plot method.  Perhaps the best approach is to plot the data as
is, and if some transformation is desired it is up to the user to do
that before plotting, that is they must pass a phylo4d with
transformed values.

> #### edges
>> treePlot(geospiza,edge.color=c("blue","green","red"), edge.width=3)
> works but I do not know if this is doing what is expected

Agreed, this is a contrived example, but follows the ape model, that
if a color or weight is specified and isn't equal to the length of the
edge, tips etc, it is repeated as necessary.  Is it better to throw an
error, or at least issue a warning for these cases?

> ####
> Also, I am not sure what we can specify as a plotting function for argument
> 'tip.plot.fun'. My understanding is that it should be any function plotting
> a numeric vector.
> I tried some without success:
>> treePlot(geospiza,show.tip=c(FALSE,FALSE),tip.plot.fun=plot)
> Error in plot.window(...) : need finite 'ylim' values
> In addition: Warning messages:
> 1: In min(x) : no non-missing arguments to min; returning Inf
> 2: In max(x) : no non-missing arguments to max; returning -Inf
>
>> treePlot(geospiza,show.tip=c(FALSE,FALSE),tip.plot.fun=boxplot)
> Error in plot.window(xlim = xlim, ylim = ylim, log = log, yaxs = pars$yaxs)
> :
> need finite 'ylim' values
> In addition: Warning messages:
> 1: In min(x) : no non-missing arguments to min; returning Inf
> 2: In max(x) : no non-missing arguments to max; returning -Inf
>
>> treePlot(geospiza,show.tip=c(FALSE,FALSE),tip.plot.fun=hist)
> Error in hist.default(t(tdata(phy, which = "tip")[i, ])) :
> invalid number of 'breaks'
>
> Sorry if I am missing something (should plotting functions be
> grid-compatible? maybe these are not, I don't know).

This is a bit tricky, currently treePlot passes one and only one
argument to plot.tip.fun, the values of tdata(phy)[i,] where i is the
tip taxa.  It should work well with grid graphics.  For further
compatibility you can load the gridBase package, however, functions
need to be formulated slightly differently.

This is how the density (a base graphic, like plot, boxplot, hist) plot is set.

tmin <- min(tdata(phy, which = 'tip'), na.rm = T)
tmax <- max(tdata(phy, which = 'tip'), na.rm = T)
tip.plot.fun <- function(x) {
    par(plt = gridPLT(), new = TRUE)
    if(!all(is.na(x))) {
        # hack, set the plotting region to the grid fig region
        dens <- density(x, na.rm = TRUE)
        plot.density(dens, xlim = c(tmin, tmax), axes = FALSE,
            mar = c(0,0,0,0), main = "", xlab = "", ylab = "")
    }
}

To do this with hist you should do something like:

data(geospiza)
ff <- function(x) {
	tmin <- min(tdata(geospiza, which = 'tip'), na.rm = T)
	tmax <- max(tdata(geospiza, which = 'tip'), na.rm = T)
	# par call required for using gridBase
    par(plt = gridPLT(), new = TRUE)
    if(!all(is.na(x))) {
        # hack, set the plotting region to the grid fig region
        hist(x, xlim = c(tmin, tmax), axes = FALSE,
            mar = c(0,0,0,0), main = "", xlab = "", ylab = "")
    }
}

# note this issues a warning, but it can be safely ignored,
# I have sent an email to the R-help list to see if it can be removed.
treePlot(geospiza, tip.plot.fun = ff)

Thanks for taking the time to look and make comments,

Peter