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

Jukes cantor likelihood #73

Merged
merged 6 commits into from
Mar 31, 2023
Merged

Jukes cantor likelihood #73

merged 6 commits into from
Mar 31, 2023

Conversation

willdumm
Copy link
Collaborator

This PR provides an implementation of Jukes Cantor likelihood on histories, with branch lengths inferred to match the expected number of mutations on each branch to the observed number of mutations on that branch.

Also included:

  • implements __contains__ method so that history in dag returns whether history is among the histories in dag
  • provides a way to estimate the number of bifurcating histories in the DAG. This was intended to provide a new way of computing node support by summing over all bifurcating trees, but those plans have been scrapped.

@willdumm willdumm requested a review from marybarker March 30, 2023 21:38
@willdumm willdumm changed the title Wd jukes cantor Jukes cantor likelihood Mar 30, 2023
@@ -913,6 +805,19 @@ def test_node_support():
assert is_close(exp(nd[node]), od[node], tol=0.0001)


def test_conditional_annotation_nilpotent():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a super fun test!

Copy link
Contributor

@marybarker marybarker left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks great! It might be good to incorporate a test that asserts likelihood implementations satisfy basic sanity tests, both to insure that and to formalize their function calls and so forth in case any calls change in future, but I don't think that is a necessary addition at this point

@matsen
Copy link
Contributor

matsen commented Mar 31, 2023

but those plans have been scrapped

Can you remind me-- this is because it just didn't work well?

@willdumm
Copy link
Collaborator Author

For now I've abandoned the idea because there doesn't seem to be a good way of counting bifurcating resolutions correctly, since the new nodes that would result from resolving a multifurcating node may already be in the DAG. I think there's something more involved that could be done that would involve changing the data structure slightly...

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

Successfully merging this pull request may close these issues.

3 participants