Hi,
I’m reading in a large number of newick trees with the same tips, all from a
single file. If I do trees<-read.trees() followed by trees <-
.compressTipLabel(trees), it reduces the memory footprint well, but takes an
age to run. I can’t help thinking this could be sped up during the reading
I wonder if reading in a Nexus file with a translation table bypasses this
problem?
JWB
Joseph W. Brown
Post-doctoral Researcher, Smith Laboratory
University of Michigan
Department of Ecology & Evolutionary Biology
Room 2071, Kraus Natural Sciences Buildin
On 14 Dec 2016, at 15:33, Joseph W. Brown wrote:
> I wonder if reading in a Nexus file with a translation table bypasses this
> problem?
Cheers,
If I try read.nexus with a TAXLABELS entry, it still (oddly) results in a
multiPhylo structure of the same size as before running .compressTipLabel
Hello,
I have one question
Is there a method to compare the support values (either bootstraps or Pp)
across all shared clades between two or more different trees having identical
taxa? I believe this method would have to first identify the shared clades and
then determine the measure of suppor
Frank:
You can import all of the trees into one or more multiPhylo objects,
then use the ape functions prop.part or prop.clades (depending on what
you want to do) to summarize different subsets (e.g., from different
analyses). Here is an example with simulated trees:
x<-rmtree(50,100)
plot(x
To clarify - the idea here is that you are asking which clades appear in
’subordinate’ trees relative to clades that exist in a consensus tree, and then
interrogating the support values of the shared clades which exist in the
’subordinate’ trees? So for example, clade A appears in consensus tree
Hi Yan,
I tried with 10,000 trees each with 1000 tips and it took a bit more
than 1 sec:
R> tr <- rmtree(1, 1000)
R> system.time(a <- .compressTipLabel(tr))
utilisateur système écoulé
1.124 0.036 1.161
And yes the memory footprint is substantially decreased:
R>
If the trees are in a NEXUS file with a TRANSLATE block, then the output
is a compressed list. So applying .compressTipLabel returns the list
unmodified (which should be almost instantaneous).
Best,
Emmanuel
Le 14/12/2016 à 16:51, Yan Wong a écrit :
On 14 Dec 2016, at 15:33, Joseph W. Brown
Hi Jake,
What you describe looks very musch like the Lento method implemented in
the function lento() in phangorn. consensusNet(), also in phangorn,
implements something similar: the consensus network.
prop.part(), in ape, is the function behind the two previous ones.
bitsplits() is more eff
On 14 Dec 2016, at 20:57, Emmanuel Paradis wrote:
> What is the size of your problem?
Erm, quite large. I am looking at tree comparison metrics for roughly 10,000
trees with perhaps 10,000 tips on each, replicated several times. The newick
files themselves take up gigabyes uncompressed. For t
On 14 Dec 2016, at 21:06, Emmanuel Paradis wrote:
> If the trees are in a NEXUS file with a TRANSLATE block, then the output is a
> compressed list. So applying .compressTipLabel returns the list unmodified
> (which should be almost instantaneous).
Ah, I see what I was doing wrong. I used a B
Hi Yan,
Joseph was right. In read.nexus you need a TRANSLATE block, just a
TAXLABELS is not enough. Then read.nexus returns the compressed object and
is 10x faster to read in (for 1000 trees with 1000 taxa on my machine).
There is also the package rncl (Nexus Class Library), it is faster to read
in
12 matches
Mail list logo