-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TreeConcordance - very sensitive to small changes in backbone #5
Comments
Hi Thomas, Thanks for getting in touch. It's great to hear that the treeConcordance idea could be useful for you and I'm sorry that's it's unsuitable for your analysis as it stands. We are in the process of redrafting that paper / code and all suggestions are very welcome. Thanks for your detailed example and yes you're absolutely right about what's going on. I can see that the function is working as intended but I agree that the emphasis on root position is giving a low score for Ind Tree 2 and obscuring the fact that a major clade is in full agreement with the category tree. It is difficult within a single score measure to capture all the possible tree differences which people may or may not care about but I will have a think about how we could handle this better. In the meantime, some ideas:
I hope that helps. Do please let me know if you have any further queries or ideas because I am keen to make this measure as useful as possible. Cheers, Michelle |
Ok great, thanks, that's helpful. I definitely need to think about this a bit more, too! In response to your "actual question": since the key difference between your "canonical" and "rearranged" trees is regarding the relative positions of blue, green, pink and yellow, could it work to just prune red out of all your trees (category and individual) and re-run treeConcordance on those pruned trees? Then the measure won't be focusing on something you don't care much about. Or am I missing something? The other thing that springs to mind is that you could run "relatedTreeDist" on all your gene trees (again, possibly after pruning out red). You may find that you get some tight clustering - in an ideal world, if you got a big cluster with 708 in the middle and a big cluster with 709 in the middle, you would have essentially sorted your trees into "canonical-like" and "rearranged-like". Of course, it probably won't be quite that tidy but I wouldn't be surprised if you see some grouping. I'd be interested to hear if that test has any power to shed light on the question. Cheers, Michelle |
Hi,
I'm trying to use treespace for the comparison of individual gene phylogenies to overall "species" phylogenies. Most of my data is from single-cell sequencing, which means individual genomes and gene sets are incomplete, and therefore tree leaf sets between trees are not identical. I was pretty excited when I read your tutorial on "Comparing trees by tip label categories" because it looks like an approach that could help me a lot with my analyses.
However, I came across an issue when trying to use treeConcordance to compare gene trees to the overall phylogeny (see figure below). The Category tree represents the expected topology for certain subclades, the two individual trees represent trees obtained from single gene families. Tree 1 is in absolute agreement with the reference tree, and also gets a treeConcordance of 1. Tree 2 is not identical, though at least naively I would say quite similar to the reference tree. However, treeConcordance is only 0.2.
After reading the tutorial more carefully and looking at the source code, I think I understand why: the "same placement" of a clade in the categorial tree and the individual tree is determined by the depth of the clade-MRCA in the tree (correct me if I am wrong). So because in Tree 2, the most basal clade is split into two clades, an additional depth level is introduced, MRCA-depths of all other clades are shifted, and they don't contribute to concordance anymore.
I guess this is the expected behaviour of the treeConcordance, although it seems counterintuitive. Unfortunately, it also makes treeConcordance unsuitable for the type of comparison I would like to do. Do you have any idea for alternative measurements, workaround or other methods that I could use in my situation?
Cheers
Thomas
The text was updated successfully, but these errors were encountered: