Bioinformatics compatability tools

[emilydolson]

When tracking phylogenies in real time, we often end up with extant (i.e. alive) taxa that are not leaf nodes. Some (possibly most or all?) bioinformatics and paleontology tools represent this scenario as "asymmetric speciation". In other words, if species A gives birth to species B but doesn't go extinct, we would represent that as

A
|
B

But they would represent it as:

     A
  __|__
 |       |
 A       B

We should add a function that does this conversion to phylotrackpy trees, for use in compatability with bioinformatics tools

[mmore500]

Wonder if the goal is compatibility with bioinformatics tools, which would require serialization i.e., to alife data standard and then conversion to another serialization format whether it would make sense to approach this as a transformation on an alife data standard record than directly on the phylotrackpy representation?

The argument against this would be if an in-memory conversion is desired before running built-in phylotrackpy tree metrics in order to be consistent with how other tools would view it, which is probably the more common occurence now that I'm thinking about it.

On Wed, Jul 5, 2023 at 12:54 PM Emily Dolson @.***> wrote:

When tracking phylogenies in real time, we often end up with extant (i.e. alive) taxa that are not leaf nodes. Some (possibly most or all?) bioinformatics and paleontology tools represent this scenario as "assymetric speciation". In other words, if species A gives birth to species B but doesn't go extinct, we would represent that as

A | B

But they would represent it as:

 A

__	__

A B

We should add a function that does this conversion to phylotrackpy trees, for use in compatability with bioinformatics tools

— Reply to this email directly, view it on GitHub https://github.com/emilydolson/phylotrackpy/issues/18, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSDYRJ6N34IQHZBY7BOID3XOXA6TANCNFSM6AAAAAAZ7M5ZEM . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- Matthew Andres Moreno https://mmore500.github.io

[emilydolson]

That's what I was thinking, but the more I think about it the more I think that could really distort a lot of the metrics. But maybe that's what people have been doing all along? Except I'm not sure how common it is to use asymmetric models?