Hi Joseph & Co,
don't trust that shallowest node has lowest node id. That is a byproduct by
functions like rtree() or read.tree(), but must not be generally true. E.g.
after tree rearrangements.
There is nothing wrong with this tree:
library(ape)
tree <- structure(list(edge = structure(c(6L, 6L,
Joseph,
Really cool. I updated the code in ape.
About (byte-)compiling, this is usually done during installing the package:
http://ape-package.ird.fr/ape_installation.html#linux
I guess Win and Mac versions from CRAN are byte-compiled. To check if a
function is compiled, just print it in R,
Emmanuel and Klaus,
After Klaus reminded me that `which` was so inefficient I realized using it in
finding the match in the first lineage is unnecessary. Instead, we can
capitalize on the fact that shallower nodes have smaller nodeids. So I threw
out the vector index `mrcaind` altogether:
Joseph, Klaus,
This is great. I slightly edited the code and renamed the argument
'tips' to 'tip' (as in the original definition). I run on a bunch of
random trees and the results are exactly identical with the current
version of getMRCA. I'm changing the code in ape now.
Cheers,
Emmanuel
w00t!
I am aware that `which` is inefficient, but wasn't sure how to get around it in
this instance. Thanks!
It would be great to have this in the new version!
Joseph.
Joseph W. Brown
Post-doctoral Researcher, Smith Laboratory
University of Michigan
Hi Joseph,
just a few changes on your code and it is actually really fast. Having
multiple calls to which() is often slow.
Replacing which() with a simple lookup table will speed your code up quite
a bit as you can see below.
This is actually how the function Ancestors() in phangorn works.
But
I've been working with some very large trees (tens to hundreds of thousands of
tips) where the speed of APE's getMRCA function has been prohibitively slow. I
therefore R-ified an MRCA function I developed in Java for use with the Open
Tree of Life tree (~3 million tips). I don't pretend to be