I just posted a new version of phytools (phytools 0.3-43) that can plot a phylogenetic tree even if branch lengths are not provided by the user. This was really trivial & I meant to do it ages ago. Basically, it just calls ape's compute.brlen internally, and then plots the tree as normal. E.g.,

It also now (like plotSimmap) sets the environmental variable "last_plot.phylo" in the environment .PlotEnvPhylo by default - so we can do this:

I'll be presenting on ancestral character estimation under the threshold model at the upcoming symposium entitled "Mathematics for an evolving biodiversity" in Montreal, Quebec in a couple of weeks. Last night, I thought it might be neat to take my existing function, bmPlot (which does discrete-time simulation & visualization under the threshold model), and modify it so that we could also visualize evolution of a threshold character up the branches of the tree.

The way I did this was by tracking the evolution of liability, translating liability into the threshold trait, and then aggregating adjacent generations with the same state into a stochastic-map style tree. Code for the new version of bmPlot is here.

One of the predictions of the threshold model is that the character should change back & forth across the threshold many times very rapidly when near the threshold. (Actually, infinitely many times in theory, under continuous time; remember, ours will be a discrete-time simulation.) That means that (compared to a 'nucleotide-model' type simulation) there some periods when the character changes very rapidly many times; and other long periods when the character doesn't change at all. Let's see how that bears out in simulation.

So our prediction appears to be exactly borne out - large parts of the tree, including very long branches, have few to no changes; however in areas when a lineage is close to one of the thresholds, it tends to change back & forth rapidly. Cool.

The way that phytools stores a tree containing a mapped discrete character (for instance, created using the functions make.simmap or sim.history) is as a standard object of class "phylo", with an additional element ($maps) which is a list of the times spent in each state (in temporal sequence from the start to the end of the edge) along each edge.

Another way to store the same information would be as a modified "phylo" object in which each edge has one state, but so-called "singleton nodes" (nodes with only one descendant edge) are permitted. Converting from phytools standard format for mapped trees to this type of object was requested of me recently by Luke Mahler. The main reason for this was to be able to convert to an object of class "ouchtree". OUCH is a package that can be used to fit the multi-optimum Ornstein-Uhlenbeck model of Butler & King (2004). OUCH does not permit multiple regimes along a single branch in the tree (although this should be allowed theoretically by the model); however the OUCH function ape2ouch (which converts between an object of class "phylo" and an "ouchtree" object) accepts singleton nodes.

I just posted this function (map.to.singleton). Just so we can see that it's doing exactly what we thing it's doing, I have also added to phytools a new function plotTree.singletons which can do basic tree plotting of trees containing singleton nodes. Here's a quick demo of how the whole thing works:

That's pretty much it.

A recent R-SIG-phylo user asked how to plot "mirror" or facing trees. This is pretty straightforward, in general. For instance, we can use cophylo.plot in the ape package to draw two facing trees in the same plot. However, there are other options as well - especially using par(mfrow) and layout. Here's a quick demo of how we can use these functions to plot facing phylogenies in their simplest forms:

If our tip labels are the same & in the same order in the two trees, we can plot the labels only once using the function layout to split our plotting area into three parts: two for the trees with no labels, and a third (the middle segment) for our centered tip labels.

The neatest thing, of course, is if we use the same approach to show the result of some of phytools custom visualizations. For instance, let's show a "contMap" plot of two different correlated characters in each of the subplots, as follows. (Note that this uses a new version of contMap from the latest non-CRAN phytools release, phytools 0.3-47.)

Cool.

A phytools user just contacted me with the following comment about the function for birth-death tree simulation, pbtree:

"Would it be helpful to add an option such that pbtree keeps trying until a tree survives, rather than returning NULL? (I'm trying to simulate a set number of trees of a set number of taxa, a proportion of which go extinct before the end of the simulation)."

Although it would be straightforward to pop this into pbtree, it is also pretty easy to write a simple wrapper script around pbtree to the same effect. For example:

Let's try it out:

In my opinion, an important caveat should be attached to this endeavor - and that is that by sampling birth-death histories conditioned on a particular outcome (survival to the present) we are only sampling from a portion of the distribution under our simulation conditions.

The effect of this is easiest to show using time-stop (rather than taxon-stop) simulations. Let's simulate with pbtree and then with our wrapper script. We'll use b, d, and t to yield an expected number of extant taxa at time t of 50.

So, you can see that when we reject all the simulations that went extinct before the present, our average number of extant taxa is much larger than the expected value of 50. This may be irrelevant, depending on the purpose of our simulation - but it is something that can be kept in mind.

An R-sig-phylo subscriber asks:

"Does anyone know of an existing function that will take a resolved tree and a number (n) as input, and randomly choose n branches to collapse to zero length?"

Here is my response, for the record:

If you don't care about the keeping the total height of the tips above the root constant, you could just do:

Let's try it out:

If you want to keep the total height of the tips constant, that's going to be a little more complicated. Maybe do this, which gives all the lost branch lengths to the daughter edges (i.e., collapses down):

Let's try this one:

That's it.

I was recently playing with simSeq in the phangorn package - but I couldn't get it to do exactly what I wanted (probably for lack of sufficient patience). Then I realized that I could (nearly) just as easily simulate DNA sequences using phytools with the function sim.history. Here's a quick & incredibly simple function that I wrote to do this that wraps around sim.history:

Yes, it's really that simple. Now, admittedly this function cannot simulate rate heterogeneity among sites, unequal base frequencies, or invariant sites, but these would be relatively straightforward to add.

Here's, let's try it out:

That works OK. Adding other attributes typical of molecular sequence models is really easy, so I'll probably do that. Pretty cool.

The post title pretty much says it all.

The only challenging thing here was dealing with time-stops (we don't know how many tips we'll end up with, so we can't specify tip labels a priori) and taxa-stop with extinction (we define this based on the number of extant lineages - if we choose to also return extinct tips, what do we call them?).

Code for the new version of the function is here, and it is in a new phytools build (phytools 0.3-49) that can be installed from source.

Here's a demo:

I just added this to the (fairly maligned) function genSeq, for simulating DNA sequences by (inefficiently) wrapping the phytools function sim.history. Here's what the function looks like now:

One can easily see that the way rate heterogeneity is handled is by allowing the user to supply a site-specific vector of rates. Here's what this would look like if we wanted to simulate sequences under a continuous Γ rate heterogeneity model with a shape parameter, α = 0.25 and a mean rate of 1.0 substitution per site per unit of branch length:

We can do invariant sites the same way - although in this case it will break the function if we set any of the rates to zero, so we need to set them very slightly > 0:

As Klaus pointed out, this method is very slow - so you probably have better options. But it's still a fun exercise to see how it works - and offers the interesting possibility that we could store and return all character histories along with the states for tips.

Yesterday I received the query:

"I want to color my tree tip labels according to a particular character and provide a legend for the same."

Here's a demo of one way to do this, using the phytools data object anoletree:

Here's the result:

Obviously, some of this is idiosyncratic to this specific dataset. Hopefully, users can figure out how to modify this to their own data and problem.

Here's something new. Luke Mahler asked me if I could create a plotting method that could take a backbone phylogeny and plot subtrees using triangles that are scaled proportionally to the number of species in the subtree. I'm still working on this, but I posted some preliminary code here.

The function takes a modified tree as an object of class "backbonePhylo". I'm going to make some functions to convert from "phylo" objects, but for now this has to be built manually. The "backbonePhylo" object is like a "phylo" object, but with tip.clade substituted for tip.label. tip.clade is a list in which each subtree is represented by a label, a number of descendant taxa, and crown group depth.

Here's a quick demo of what can be done so far:

Cool. That's more or less what we were going for.

Yesterday (more accurately, early this morning), I posted about a new plotting method for plotting a backbone phylogeny with diversities for each subtree represented as a triangle. This type of visualization is quite common in the literature; however, I'm told (by Luke Mahler, so blame him if this is incorrect) that there is no such plotting method so far in R.

The way I did this was by first creating a new type of phylogeny object, of class "backbonePhylo". This object is stored in a very similar way to the typical phylogeny object in R (class "phylo"), which the exception that we have replaced the vector tip.label with the list tip.clade. tip.clade is a list in which each element contains a label, a diversity (i.e., the number of tips hidden in the subtree), and a crown depth.

I have written some of the methods around this object as S3 methods, which means they can be dispatched using (for instance) calls to the generic plot, reorder, print, etc.

This morning, I did a little more work on this suite of functions. Most importantly, I created a new function (phylo.toBackbone) that converts an object of class "phylo" to an object of class "backbonePhylo" with the help of a translation table. The translation table is a data frame with four variables: tip.label (containing the names of the tips in the input tree - these might be exemplar taxa); label (containing the names of the subtrees - these might be the names of higher taxa); N (obviously, the diversities of each subtree); and depth (the age of each crown group, in terms of the branch lengths of the input tree - note that this cannot be longer then the corresponding tip edge). Note that not all tips in the original tree need to be in the translation table. Those that are not will be treated as clades containing one taxon in the backbone tree.

Here's a demo using random subtree sizes on a stochastic backbone tree. New code for this is here.

That's pretty good.

This is pretty much guaranteed to be the last post on this topic today, but I made some additional refinements of plot.backbonePhylo, my new plotting method to show subtrees as triangles.

The three main changes are as follows: (1) following Luke's suggestion, subtrees containing only 1 taxon are now plotted as a line (actually - a triangle with zero width, but I guarantee you won't be able to tell the difference), instead of as a triangle with unit width; (2) following Graham Slater's suggestion, I made a small change so that there is a space between adjacent triangles - the consequence is that clades with 2 taxa are of unit length, clades with 10 taxa are 9 units in width, etc., which actually lines up with tips containing 1 taxon, which now have unit width; and (3) I added the optional scaling factor vscale, which scales the vertical dimension so that large subtrees can be portrayed while still allowing singletons and spacing between triangles.

All of these updates are available here, but are also part of a new phytools build (phytools 0.3-51).

Here's a demo:

Pretty cool.

We have to be careful with this, though, because if we adjust our clade widths such that any are less than 1 unit then we are going to get some really weird plots.

The phangorn function RF.dist - for computing the Robinson-Foulds distance between two trees - is very fast. However if we want to compare a set of trees stored in an object of class "multiPhylo" there is some opportunity to recycle internal calculations & thus improve on just calling RF.distn× (n - 1) / 2 times for n trees. Specifically, here is some code that scales to multiple trees a little bit better than n× (n - 1) / 2 RF.dist by calling the ape function prop.part (which finds all bipartitions in the tree) only once for each tree:

It works OK compared to calling RF.dist a whole bunch of times independently. First, here is an alternate version of the function which uses RF.dist:

Now, a very simple comparison with random trees:

I just posted a slightly faster version of multiRF that takes advantage of the fact that the first element in the list of tree bipartitions from prop.part of the ape package is the "partition" with all the taxa in the tree - which can be ignored if our two input trees have the same taxa (they should). The result is about a 20% speed-up in the 100 × 99 ÷ 2 comparisons for 100, 100-taxon trees.

Here's a demo using my i3 Asus Vivobook (obviously - it would be much faster on a speedy desktop):

BTW, I just submitted phytools 0.3-60 to CRAN - so hopeful it is accepted & percolates through the mirror repositories this week.

A little while ago I received the following query:

"To account for body size I used the phylogenetic regression of your phyl.resid function. I used the mean value of each trait per species. However, now I would like to plot the residuals against the ecological variables to show how they relate, including standard deviations for trait means. Is there a way to calculate phylogenetically corrected residuals with standard deviations? Or simply calculate residuals for more than one individual per species?"

Well, there are multiple ways we could go about doing this - with multiple possible solutions. The simplest thing, and the one I'd probably recommend for starters, is to fit the phylogenetic regression to x̄ and ȳ, the species means vectors; but then compute ŷ = [1 x]β and e = y - ŷ from the original data vectors, x&y.

Here's how that would look if we had input data vectors xi and yi, both with the same order but in which names(xi) and names(yi) contain only species names (& thus no unique identifiers):

Note that the species-wise mean of ei will be exactly equal to our residuals from the fitted model using species means. E.g., compare:

That's it!

A phytools user asks:

"I have a list of names that correspond exactly to the tips of a phylogenetic tree. What i'd like to do is obtain the branch lengths that correspond to these tip edges."

This can be done with one line:

We get a vector with all the terminal edge lengths with names set to all the tip names in the tree, so we can rearrange or select a subset of these tip lengths on that basis.

Let's check it:

Today I got the following interesting user request:

"I have been playing around with the function pgls.Ives. Is there anyway to accomodate the corPagel correlation structures into this?"

This is not possible, actually. corStruct objects (such as an object of class "corPagel") do not permit (so far as I know) error in both x & y which is a component of the pgls.Ives model. However we can, with a little pain, optimize Pagel's λ model using pgls.Ives - just in a slightly roundabout way. We do this by building a simple wrapper around pgls.Ives that spits out the log-likelihood conditioned on a specific input λ, then we optimize for λ. Here's a demo:

Let's try it:

Note that although this works fine in principle, I have received some reports of the basic function failing to optimize for larger trees - and I believe these reports, so please use pgls.Ives with considerable caution until I work out these issues!

I'm running some tests on phytools right now to try and put a new version on CRAN, but one of them required I use the function lambdaTree in the geiger package. geiger is not a dependency of phytools, so I wanted to be able to do this (ideally) without loading geiger. Here is a simplified lambdaTree (now deprecated into transform.phylo):

Here's a quick check:

A new version of phytools (phytools 0.3-72) is now on CRAN. It's been a few months since the previous CRAN version. This is partly because I had to do some work on the minor phytools versions that I've been posting to bring them into compliance with changing CRAN standards. For instance, CRAN now encourages functions that are used in package dependencies to also be imported using importFrom in the NAMESPACE file, and foreign function calls to compiled C code in other packages are no longer generally permitted (or, at least, they are actively discouraged).

Here's a (possibly non-comprehensive) list of updates/new functions/etc. in the current CRAN version of phytools relative to the last CRAN release (phytools 0.3-10):

1. An update to phyl.cca that results when spectral decomposition produces slightly negative eigenvalues (due to limitations on numerical precision) for a positive semi-definite covariance matrix.

2. An update to densityMap to allow users to plot the variation among stochastic maps.

3. A new function (phylo.to.map, and S3 plotting method) to visual a phylogeny connected to or projected onto a geographic map (1, 2, 3).

4. A new version of mergeMappedStates to merge two or more mapped states on a stochastic map tree.

5. A new function (drop.leaves) to strip all the leaves off of a phylogenetic tree.

6. A new version of ancThresh (for ancestral character estimation under the threshold model) which also permits us to fit an OU model for the evolution of liability on the tree.

7. Major updates to the innards of the important phytools plotting function plotSimmap.

8. An update to plotSimmap(...,type="fan") to permit node labels.

9. A new 'static' plotting method for phylomorphospace3d.

10. A new version of plotTree that will supply branch lengths using compute.brlen in 'ape' if none are provided.

11. An update to bmPlot(...,type="threshold") which also maps the (discrete generation) history of a threshold character on the branches of a phylogeny & returns this tree to the user.

12. A new function (map.to.singleton) that converts a tree with a mapped character to a tree with singleton nodes; and a new plotting method (plotTree.singletons) for plotting these trees.

13. A new version of contMap (and, in fact, densityMap) to allow users to plot left-facing trees.

14. A simple DNA evolution simulator (genSeq) that wraps around sim.history (1, 2).

15. A new version of pbtree that allows user-defined tip labels.

16. A new set of methods to plot a backbone phylogeny with triangles as subtrees (1, 2, 3).

17. A new function (multiRF) for computing all pairwise Robinson-Foulds distances for a set of trees that recycles internals to be slightly speedier (1, 2).

18. Additional minor updates to branching.diffusion, xkcdTree, anc.trend, phylomorphospace3d, strahlerNumber, and map.to.singleton.

19. Minor updates to the documentation of various functions.

In addition to these changes, and as I alluded above, I made a bunch of additional updates (that will generally be hidden to the user) to the way phytools depends on other packages. I did this primarily to bring phytools into compliance with evolving CRAN standards. Hopefully none of these changes affect phytools users adversely.

Obviously, keep in mind that it may take a few days for Mac & Windows phytools binaries to be build & for the updated version of phytools to percolate through all the CRAN mirrors.

Thanks for using phytools!