{"action":"created","issue":{"url":"https://api.github.com/repos/tskit-dev/msprime/issues/553","repository_url":"https://api.github.com/repos/tskit-dev/msprime","labels_url":"https://api.github.com/repos/tskit-dev/msprime/issues/553/labels{/name}","comments_url":"https://api.github.com/repos/tskit-dev/msprime/issues/553/comments","events_url":"https://api.github.com/repos/tskit-dev/msprime/issues/553/events","html_url":"https://github.com/tskit-dev/msprime/issues/553","id":339258449,"node_id":"MDU6SXNzdWUzMzkyNTg0NDk=","number":553,"title":"More general mutation models","user":{"login":"petrelharp","id":1046249,"node_id":"MDQ6VXNlcjEwNDYyNDk=","avatar_url":"https://avatars2.githubusercontent.com/u/1046249?v=4","gravatar_id":"","url":"https://api.github.com/users/petrelharp","html_url":"https://github.com/petrelharp","followers_url":"https://api.github.com/users/petrelharp/followers","following_url":"https://api.github.com/users/petrelharp/following{/other_user}","gists_url":"https://api.github.com/users/petrelharp/gists{/gist_id}","starred_url":"https://api.github.com/users/petrelharp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/petrelharp/subscriptions","organizations_url":"https://api.github.com/users/petrelharp/orgs","repos_url":"https://api.github.com/users/petrelharp/repos","events_url":"https://api.github.com/users/petrelharp/events{/privacy}","received_events_url":"https://api.github.com/users/petrelharp/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2018-07-08T21:15:07Z","updated_at":"2018-07-09T17:20:42Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"We'd like to provide support for other models of mutation. Here is a proposal for how to do this, in a two-stage protocol, that separates generating locations of the mutations (which can be done independently on each edge) from allelic states.  We'd need to do two things:\r\n\r\n**Finite sites, parent-independent mutation:**  First, we need to modify the current algorithm to produce mutations at a finite set of sites.\r\n\r\n- I'd propose for this to be *only* at integer locations; we could make the set of possible locations more general, but why bother? \r\n\r\n- These mutations would be generated *independently* on each edge, and derived state could be random floats in `[0,1)` to ensure uniqueness (and stored as bytes).\r\n\r\n- We would not need to specify the mutation `parent` property, because it could be done afterwards with `compute_mutation_parent()` if we traversed the edges in order by forwards-time.\r\n\r\n**Transformation to finite-state model:** The next step is to convert the mutations produced in the first step -- *or* the mutations produced by the infinite-sites model -- to a finite-state model, e.g., Jukes-Cantor.  To do this:\r\n\r\n1. We'd be provided with an alphabet of length $m$, a distribution $\\pi_i$ for the root state, and a $m \\times m$ matrix $Q_{ij}$ that gives the rate at which allele $i$ mutates into allele $j$, with $Q_{ii} = 0$. We then define $\\mu = \\max_i \\sum_j Q_{ij}$ and $P_{ij} = Q_{ij} / \\mu$ for $i \\neq j$ and $P_{ii} = 1 - \\sum_{j \\neq i} P_{ij}$.\r\n\r\n2. We generate parent-independent mutations as above using mutation rate $\\mu$, and use `compute_mutation_parents` to find the mutation parents.\r\n\r\n3. We step through the sites:\r\n\r\n    - generating for each site an ancestral state $i$ from $\\pi$, and\r\n    - generating a derived allele for each mutation from probabilities $P_{ij}$; if the derived state is $i$ then we discard the mutation.\r\n\r\nNote that thanks to having mutation parents we don't need to generate the trees to do this. Also note that if the derived states produced by parent-independent mutation are random floats, we don't need to produce any more randomness to do this.\r\n\r\n**Advantages to this decoupled scheme:**\r\n\r\nThe main advantage to this scheme is it simplifies bookkeeping: \r\n\r\n   - mutation locations are chosen while only looking at the edge table\r\n   - tree topology only needs to be parsed while computing the mutation parent column\r\n   - allelic identity of mutations then only needs to look at the mutation and site table\r\n\r\nThis decoupling is totally general, and should make it easy to implement new models.\r\n\r\n**Disadvantages:**\r\n\r\n- We end up generating more mutations than we need to.\r\n- Storing floats as bytes in the derived state seems inefficient.\r\n- Incorporating existing mutations makes this more complicated.\r\n\r\ncc @molpopgen "},"comment":{"url":"https://api.github.com/repos/tskit-dev/msprime/issues/comments/403554595","html_url":"https://github.com/tskit-dev/msprime/issues/553#issuecomment-403554595","issue_url":"https://api.github.com/repos/tskit-dev/msprime/issues/553","id":403554595,"node_id":"MDEyOklzc3VlQ29tbWVudDQwMzU1NDU5NQ==","user":{"login":"molpopgen","id":6416159,"node_id":"MDQ6VXNlcjY0MTYxNTk=","avatar_url":"https://avatars0.githubusercontent.com/u/6416159?v=4","gravatar_id":"","url":"https://api.github.com/users/molpopgen","html_url":"https://github.com/molpopgen","followers_url":"https://api.github.com/users/molpopgen/followers","following_url":"https://api.github.com/users/molpopgen/following{/other_user}","gists_url":"https://api.github.com/users/molpopgen/gists{/gist_id}","starred_url":"https://api.github.com/users/molpopgen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/molpopgen/subscriptions","organizations_url":"https://api.github.com/users/molpopgen/orgs","repos_url":"https://api.github.com/users/molpopgen/repos","events_url":"https://api.github.com/users/molpopgen/events{/privacy}","received_events_url":"https://api.github.com/users/molpopgen/received_events","type":"User","site_admin":false},"created_at":"2018-07-09T17:20:42Z","updated_at":"2018-07-09T17:20:42Z","author_association":"CONTRIBUTOR","body":"> It is not at all obvious how to add new mutations to an existing set when not under the infinite sites mdoel. The only thing to do, really, is to suppose any existing mutations fall somewhere uniformly at random on the edge, so that a new mutations on the same edge fall randomly interspersed. But, why would we even want to leave existing mutations? The only use case I'm aware of is when the existing mutations are non-neutral, in which case we don't actually want to add more mutations to those sites.\r\n> So, my proposal is that the finite-sites mutation model, when preserving existing mutations, actually does not place any new mutations at already mutated sites. (And, not rejection sample, but when proposing to mutate an already-mutated site, should just do nothing.)\r\n\r\nImagine the scenario where you evolve for some amount of time, and then do some analysis, and then evolve some more.  There's a chance that the state will change at already-mutated sites, and it seems that this case should be supported."}}
{"actor":{"display_login":"molpopgen"}}