Skip to content
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

possible enhancement: retain edge identity when rerooting #54

Open
mtholder opened this issue May 17, 2016 · 1 comment
Open

possible enhancement: retain edge identity when rerooting #54

mtholder opened this issue May 17, 2016 · 1 comment

Comments

@mtholder
Copy link
Collaborator

This is a low priority request, and may not be a great idea...

When you are rerooting at an existing node and the tree is currently rooted at a polytomy, the number of nodes and edges in the tree does not change.
It would be somewhat nice if the rerooting were accomplished by flipping edges so that the mapping between an edge and the (unrooted) bipartition of taxa was maintained. This is not currently done.

An example, when writing https://gist.github.com/mtholder/8c5a4079d04a0129c652e431575add01 I tried:

  def edge_label_method():
    tree = get_tree()
    for edge in tree.preorder_edge_iter():
        h = edge.head_node
        if not h.is_leaf():
            edge.label = h.label
    tree.seed_node.label =''
    outgroup_node = tree.find_node_with_taxon_label("X")
    new_root = outgroup_node.parent_node
    tree.reseed_at(new_root)
    for edge in tree.preorder_edge_iter():
        h = edge.head_node
        if not h.is_leaf():
            h.label = edge.label
    new_root.label = ''
    return tree

but this did not work because of the lack of persistence of edge identity.

@jeetsukumaran
Copy link
Owner

jeetsukumaran commented May 17, 2016

Yes, this would be useful. It comes down to whether we see edges as connecting nodes or connecting bipartitions: #53 (comment)

The former viewpoint is pervasive (third time I've used that word today) and seems, at first glance, more natural. But really it is a waste of an edge object, because all the information associated with the "edge" can just be dumped onto the node, as there is a strict one-to-one correspondence between edges and the subtended nodes.

The second viewpoint, on the other hand, does bring something very different and useful to the table. But shifting to support this second on does involve refactoring of the low-level architecture. Probably not a big deal as very few people use it. [EDIT: I mean, very few people use the low-level architecture, so a shift will not break too much code in the wild. But break some code it will ...]

I guess you are suggesting swapping nodes out but keeping edges in-place? The problem is that to simplifying synchronization/book-keeping, and reinforcing the now, in retrospect, unfortunately redundant one-to-one correspondence between an edge and its subtended node, I long ago discarded tail_node as an independent object on an edge. This now references self.head_node.parent_node. Need to conisder carefully if this will break things.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants