You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@metasoarous has added the inferred naive name to the reconstruction objects created by cft to represent trees. Once he pushes that to the working version of cft, we will want to read that inferred naive name out in Olmsted so we can update our code that just looks for the root node. Alternatively, @metasoarous do you think it makes sense to rely on our data script for olmsted which uses ete3 to convert the newick string into a PhyloTree object and traverse it and assume the node we end our traversal (postorder) on, which has no parent is in fact the naive? Then we could decouple olmsted from concerns about the name of the naive. We'd still have a naive, and it still would have a name, we'd just find it by it having the property type: root
The text was updated successfully, but these errors were encountered:
I'd rather stick with the explicit specification in the json data. Maybe we could do something like what you suggest as a default though in case its not there?
@metasoarous has added the inferred naive name to the reconstruction objects created by cft to represent trees. Once he pushes that to the working version of cft, we will want to read that inferred naive name out in Olmsted so we can update our code that just looks for the root node. Alternatively, @metasoarous do you think it makes sense to rely on our data script for olmsted which uses ete3 to convert the newick string into a
PhyloTree
object and traverse it and assume the node we end our traversal (postorder) on, which has no parent is in fact the naive? Then we could decouple olmsted from concerns about the name of the naive. We'd still have a naive, and it still would have a name, we'd just find it by it having the propertytype: root
The text was updated successfully, but these errors were encountered: