[R-sig-phylo] Why no branch lengths on consensus trees?
When making a consensus tree using ape::consensus the branch lengths are lost. Is there a way to not lose the branch lengths? Or to add them somehow to the consensus tree after making it. library(ape) cat(owls(((Strix_aluco:4.2,Asio_otus:4.1):4.1,Athene_noctua:7.3):6.3,Tyto_alba:13.5);, file = ex1.tre, sep = \n) cat(owls(((Strix_aluco:1.2,Asio_otus:4.5):3.1,Athene_noctua:7.3):6.3,Tyto_alba:13.5);, file = ex2.tre, sep = \n) cat(owls(((Strix_aluco:3.2,Asio_otus:4.7):8.1,Athene_noctua:7.3):6.3,Tyto_alba:13.5);, file = ex3.tre, sep = \n) tree1 - read.tree(ex1.tre) tree2 - read.tree(ex2.tre) tree3 - read.tree(ex3.tre) trees - c(tree1, tree2, tree3) trees_con - consensus(trees) trees_con Phylogenetic tree with 4 tips and 3 internal nodes. Tip labels:[1] Strix_aluco Asio_otus Athene_noctua Tyto_alba Rooted; no branch lengths. Thanks, Scott Chamberlain [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Why no branch lengths on consensus trees?
Dear Scott, What should branch lengths on a consensus tree represent? They cannot be expected substitutions per residue. This would imply no evolution at points where uncertain branching patterns have been reduced to a multi-furcation - which is not what the multi-furcation is meant to imply. (Rather: there was evolution, but we aren't very certain about the branching pattern.) But, MrBayes does provide average lengths of some kind. Best wishes, Daniel On 21/11/2012 15:13, Scott Chamberlain myrmecocys...@gmail.com wrote: When making a consensus tree using ape::consensus the branch lengths are lost. Is there a way to not lose the branch lengths? Or to add them somehow to the consensus tree after making it. library(ape) cat(owls(((Strix_aluco:4.2,Asio_otus:4.1):4.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex1.tre, sep = \n) cat(owls(((Strix_aluco:1.2,Asio_otus:4.5):3.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex2.tre, sep = \n) cat(owls(((Strix_aluco:3.2,Asio_otus:4.7):8.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex3.tre, sep = \n) tree1 - read.tree(ex1.tre) tree2 - read.tree(ex2.tre) tree3 - read.tree(ex3.tre) trees - c(tree1, tree2, tree3) trees_con - consensus(trees) trees_con Phylogenetic tree with 4 tips and 3 internal nodes. Tip labels:[1] Strix_aluco Asio_otus Athene_noctua Tyto_alba Rooted; no branch lengths. Thanks, Scott Chamberlain [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo -- Daniel Barker http://bio.st-andrews.ac.uk/staff/db60.htm The University of St Andrews is a charity registered in Scotland : No SC013532 ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Why no branch lengths on consensus trees?
I have a function to create a consensus tree with branch lengths. You feed it a given topology (often a consensus topology, made with ape), then a list of trees, and tell it what you want the branch lengths to represent. It could be the proportion of input trees with that edge (good for summarizing bootstrap or Bayes proportions) or the mean, median, or sd of branch lengths for those trees that have that edge. Consensus branch lengths in units of proportion of matching trees has obvious utility. As Daniel says, the average branch lengths across a set of trees is more difficult to see a use case for, but you could imagine doing something like taking the ratogram output from r8s on a set of trees and summarizing the rate average and rate sd on a given, best, tree as two sets of branch lengths on that tree. I've put the function source at https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R/consensusBrlen.R?revision=110root=omearalab. You can source the file for the function (consensusBrlen() ) and other functions it needs. It also uses phylobase. Note that this is alpha-quality code -- it's been checked a bit, but verify it's doing what you want. Here's an example of how to use it library(ape) library(phylobase) phy.a-rcoal(15) phy.b-phy.a phy.b$edge.length-phy.b$edge.length+runif(length(phy.b$edge.length), 0, 0.1) phy.c-rcoal(15) phy.list-list(phy.a, phy.b, phy.c) phy.consensus-consensusBrlen(phy.a, list(phy.a, phy.b, phy.c), type=mean_brlen) Best, Brian PS: Note that I am actively looking for grad students: info at http://www.brianomeara.info/lab . Guaranteed five years support, subject to decent performance. ___ Brian O'Meara Assistant Professor Dept. of Ecology Evolutionary Biology U. of Tennessee, Knoxville http://www.brianomeara.info Students wanted: Applications due Dec. 15, annually Postdoc collaborators wanted: Check NIMBioS' website Calendar: http://www.brianomeara.info/calendars/omeara On Wed, Nov 21, 2012 at 11:09 AM, Daniel Barker d...@st-andrews.ac.ukwrote: Dear Scott, What should branch lengths on a consensus tree represent? They cannot be expected substitutions per residue. This would imply no evolution at points where uncertain branching patterns have been reduced to a multi-furcation - which is not what the multi-furcation is meant to imply. (Rather: there was evolution, but we aren't very certain about the branching pattern.) But, MrBayes does provide average lengths of some kind. Best wishes, Daniel On 21/11/2012 15:13, Scott Chamberlain myrmecocys...@gmail.com wrote: When making a consensus tree using ape::consensus the branch lengths are lost. Is there a way to not lose the branch lengths? Or to add them somehow to the consensus tree after making it. library(ape) cat(owls(((Strix_aluco:4.2,Asio_otus:4.1):4.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex1.tre, sep = \n) cat(owls(((Strix_aluco:1.2,Asio_otus:4.5):3.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex2.tre, sep = \n) cat(owls(((Strix_aluco:3.2,Asio_otus:4.7):8.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex3.tre, sep = \n) tree1 - read.tree(ex1.tre) tree2 - read.tree(ex2.tre) tree3 - read.tree(ex3.tre) trees - c(tree1, tree2, tree3) trees_con - consensus(trees) trees_con Phylogenetic tree with 4 tips and 3 internal nodes. Tip labels:[1] Strix_aluco Asio_otus Athene_noctua Tyto_alba Rooted; no branch lengths. Thanks, Scott Chamberlain [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo -- Daniel Barker http://bio.st-andrews.ac.uk/staff/db60.htm The University of St Andrews is a charity registered in Scotland : No SC013532 ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Why no branch lengths on consensus trees?
Dear Brian, Awesome. Thanks for sharing the code Brian. I will give it a try. I see what you all mean now more precisely with the question of what does it really mean to have branch lengths on a consensus tree. Thanks, Scott On Wed, Nov 21, 2012 at 11:10 AM, Brian O'Meara bome...@utk.edu wrote: I have a function to create a consensus tree with branch lengths. You feed it a given topology (often a consensus topology, made with ape), then a list of trees, and tell it what you want the branch lengths to represent. It could be the proportion of input trees with that edge (good for summarizing bootstrap or Bayes proportions) or the mean, median, or sd of branch lengths for those trees that have that edge. Consensus branch lengths in units of proportion of matching trees has obvious utility. As Daniel says, the average branch lengths across a set of trees is more difficult to see a use case for, but you could imagine doing something like taking the ratogram output from r8s on a set of trees and summarizing the rate average and rate sd on a given, best, tree as two sets of branch lengths on that tree. I've put the function source at https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/R/consensusBrlen.R?revision=110root=omearalab. You can source the file for the function (consensusBrlen() ) and other functions it needs. It also uses phylobase. Note that this is alpha-quality code -- it's been checked a bit, but verify it's doing what you want. Here's an example of how to use it library(ape) library(phylobase) phy.a-rcoal(15) phy.b-phy.a phy.b$edge.length-phy.b$edge.length+runif(length(phy.b$edge.length), 0, 0.1) phy.c-rcoal(15) phy.list-list(phy.a, phy.b, phy.c) phy.consensus-consensusBrlen(phy.a, list(phy.a, phy.b, phy.c), type=mean_brlen) Best, Brian PS: Note that I am actively looking for grad students: info at http://www.brianomeara.info/lab . Guaranteed five years support, subject to decent performance. ___ Brian O'Meara Assistant Professor Dept. of Ecology Evolutionary Biology U. of Tennessee, Knoxville http://www.brianomeara.info Students wanted: Applications due Dec. 15, annually Postdoc collaborators wanted: Check NIMBioS' website Calendar: http://www.brianomeara.info/calendars/omeara On Wed, Nov 21, 2012 at 11:09 AM, Daniel Barker d...@st-andrews.ac.ukwrote: Dear Scott, What should branch lengths on a consensus tree represent? They cannot be expected substitutions per residue. This would imply no evolution at points where uncertain branching patterns have been reduced to a multi-furcation - which is not what the multi-furcation is meant to imply. (Rather: there was evolution, but we aren't very certain about the branching pattern.) But, MrBayes does provide average lengths of some kind. Best wishes, Daniel On 21/11/2012 15:13, Scott Chamberlain myrmecocys...@gmail.com wrote: When making a consensus tree using ape::consensus the branch lengths are lost. Is there a way to not lose the branch lengths? Or to add them somehow to the consensus tree after making it. library(ape) cat(owls(((Strix_aluco:4.2,Asio_otus:4.1):4.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex1.tre, sep = \n) cat(owls(((Strix_aluco:1.2,Asio_otus:4.5):3.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex2.tre, sep = \n) cat(owls(((Strix_aluco:3.2,Asio_otus:4.7):8.1,Athene_noctua:7.3):6.3,Tyt o_alba:13.5);, file = ex3.tre, sep = \n) tree1 - read.tree(ex1.tre) tree2 - read.tree(ex2.tre) tree3 - read.tree(ex3.tre) trees - c(tree1, tree2, tree3) trees_con - consensus(trees) trees_con Phylogenetic tree with 4 tips and 3 internal nodes. Tip labels:[1] Strix_aluco Asio_otus Athene_noctua Tyto_alba Rooted; no branch lengths. Thanks, Scott Chamberlain [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo -- Daniel Barker http://bio.st-andrews.ac.uk/staff/db60.htm The University of St Andrews is a charity registered in Scotland : No SC013532 ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] Why no branch lengths on consensus trees?
Dear Joe, Thanks for your feedback on this question. I will go read those pages you mentioned. Scott On Wed, Nov 21, 2012 at 5:19 PM, Joe Felsenstein j...@gs.washington.eduwrote: Daniel Barker wrote: What should branch lengths on a consensus tree represent? Scott Chamberlain had written: When making a consensus tree using ape::consensus the branch lengths are lost. Is there a way to not lose the branch lengths? Or to add them somehow to the consensus tree after making it. The issue of what branch lengths ought to be on a consensus tree is not simple. If we have three rooted trees: ((A:1,B:1):1,C:2); ((A:1,B:1):1,C:2); (A:2,(B:1,C:1):1); the consensus tree should be the first tree, but what branch length should be used for (say) the branch ancestral to the AB clade? 1? 0.667? The minute you open this can of worms it becomes clear that the answer depends on what you want that number to convey and what interpretations your audience will tend to draw from the number. There is no obvious answer. So this is not a mere technical computing question. By the way, in my 2004 book, you will find me agonizing about this on page 526, coming down on the side of 0.667, but not overwhelmingly convincingly. You could argue that a branch length should be set 0 when the branch is not there, and all the resulting values averaged, or you could argue that the average should only be taken over those trees for which that branch is present. One possible way to solve the problem is to take the consensus tree as if it were a user-defined tree, use your whole data set, and infer branch lengths on that tree. Daniel has already expressed his legitimate concerns in such a case as to whether it takes (for example) trifurcations as if they were real rather than an expression of our uncertainty. J.F. Joe Felsenstein j...@gs.washington.edu Department of Genome Sciences and Department of Biology, University of Washington, Box 355065, Seattle, WA 98195-5065 USA (from 1 October 2012 to 10 December 2012 on sabbatical leave at) Department of Statistics, University of California, Berkeley, 367 Evans Hall, Berkeley, CA 94710 [[alternative HTML version deleted]] ___ R-sig-phylo mailing list R-sig-phylo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
Re: [R-sig-phylo] drop.tip weird handling of node labels
Dear Tristan,
Thanks alot for spotting this. This is fixed now. The new version is
available here:
https://svn.mpl.ird.fr/ape/dev/ape/R/drop.tip.R
More tests will be welcome.
Cheers,
Emmanuel
Tristan Lefebure wrote on 15/11/2012 18:09:
Dear all,
I am puzzled with the following dropt.tip behaviour:
##
require(ape)
tr-
read.tree(text='(((t1:1.047859182,t2:1.047859182):0.2756716989,t3:1.323530881):0.9374413868,(t4:1.004540609,(t5:0.825851211,t6:0.825851211):0.1786893979):0.2456960053,((t7:1.056756599,t8:1.056756599):0.06431900218,t9:1.121075601):0.1291610131):0.3349743758,t10:1.58521099):0.2527177518,((t11:0.7045266296,t12:0.7045266296):0.9569230276,(t13:1.434588187,t14:1.434588187):0.2268614706):0.1764790846):0.08226490869,t15:1.279204276,((t16:1.114074687,t17:1.114074687):0.1122507672,t18:1.226325454):0.05287882165):0.1013794601,t19:0.9955287763,t20:0.9955287763):0.1328862159,(((t21:0.5523867955,t22:0.5523867955):0.2108511243,t23:0.7632379198):0.1651743381,((t24:0.6573230631,t25:0.6573230631):0.1870302034,(t26:0.7107704271,t27:0.7107704271):0.1335828394):0.08405899131):0.227343):0.1056949204,(t28:1.153531955,t29:1.153531955):0.08057795766):0.05156567335,((t30:0.7944490533,t31:0.7944490533):0.3247998092,(((t32:0.6657996502,t33:0.6657996502):0.1778661928,((t34:0.1423836508!
,t!
35:0.1423836508):0.5359910966,t36:0.6783747474):0.1652910955):0.08026277837,t37:0.9239286214):0.1953202411):0.1664267234):0.0949081502):0.06478712445,(((t38:0.7909217241,(t39:0.404267298,t40:0.404267298):0.3866544261):0.4221751735,((t41:0.9390399711,t42:0.9390399711):0.1900443404,(t43:0.7331382087,(t44:0.5724991151,(t45:0.4288431567,t46:0.4288431567):0.1436559584):0.1606390935):0.0802190135,t47:0.813357):0.09505692675,t48:0.9084141489):0.1203866568,(((t49:0.748033,t50:0.748033):0.081110064,(t51:0.4635806844,t52:0.4635806844):0.3575301829):0.09861132464,t53:0.9197221919):0.1090786138):0.03016346022,(t54:0.7468362228,t55:0.7468362228):0.3121280432):0.07012004561):0.08401258605):0.1109195687,t56:1.324016466):0.1213543942):0.1153375546,((t57:1.136226544,t58:1.136226544):0.2488130821,(t59:0.493435228,t60:0.493435228):0.8916043976):0.1756687895):0.3594852354):0.3407786169);')
torm- paste('t',
c(2,3,4,6,10,11,12,17,18,26,29,33,37,38,41,45,46,51,52,53,55), sep='')
tr$node.label- paste('n', 1:Nnode(tr), sep='')
x11(); plot(tr, cex=0.7); nodelabels(tr$node.label, cex=0.7);
tr2- drop.tip(tr, torm)
x11(); plot(tr2, cex=0.7); nodelabels(tr2$node.label, cex=0.7);
#
Just look at the top clade made of t60, t59, t57 and t57. This clade is not
impacted by the tree pruning; but look at the node labels, they have been
badly reassigned... I've tried to replicate the problem on a smaller data
set, but did not succeed.
Thanks!
--
Tristan Lefebure
[[alternative HTML version deleted]]
___
R-sig-phylo mailing list
R-sig-phylo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
--
Emmanuel Paradis
IRD, Jakarta, Indonesia
http://ape.mpl.ird.fr/
___
R-sig-phylo mailing list
R-sig-phylo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-phylo
