{"action":"closed","issue":{"url":"https://api.github.com/repos/psathyrella/partis/issues/22","repository_url":"https://api.github.com/repos/psathyrella/partis","labels_url":"https://api.github.com/repos/psathyrella/partis/issues/22/labels{/name}","comments_url":"https://api.github.com/repos/psathyrella/partis/issues/22/comments","events_url":"https://api.github.com/repos/psathyrella/partis/issues/22/events","html_url":"https://github.com/psathyrella/partis/issues/22","id":51871499,"number":22,"title":"More low priority TODOs","user":{"login":"psathyrella","id":2960243,"avatar_url":"https://avatars.githubusercontent.com/u/2960243?v=3","gravatar_id":"","url":"https://api.github.com/users/psathyrella","html_url":"https://github.com/psathyrella","followers_url":"https://api.github.com/users/psathyrella/followers","following_url":"https://api.github.com/users/psathyrella/following{/other_user}","gists_url":"https://api.github.com/users/psathyrella/gists{/gist_id}","starred_url":"https://api.github.com/users/psathyrella/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/psathyrella/subscriptions","organizations_url":"https://api.github.com/users/psathyrella/orgs","repos_url":"https://api.github.com/users/psathyrella/repos","events_url":"https://api.github.com/users/psathyrella/events{/privacy}","received_events_url":"https://api.github.com/users/psathyrella/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/psathyrella/partis/labels/prio:low","name":"prio:low","color":"fef2c0"}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2014-12-13T01:27:49Z","updated_at":"2016-09-27T19:03:58Z","closed_at":"2016-09-27T19:03:58Z","body":"  - if hamming distance is *very* small could precluster the *other* way, i.e. assume pairs are in the same event\r\n  - stop using hackey versions of gtr.txt and trees.tre in recombinator. I.e. start inferring phylogenies\r\n  - tree inference closure tests in recombinator\r\n  - synchronize replacement_gene treatment for *all* parameters between hmmwriter and recombinator\r\n  - account for different mutation frequencies to different bases (it seems that this will require forking bppseqgen)\r\n  - add recombinator run to scons test\r\n  - optimizing recombinator:\r\n    - indeed it seems to be all in generating the mutants with bppseqgen\r\n      - if I switch to a tree with ten times the tips, but then generate the same number of sequences as before, it runs like a hundred times faster\r\n    - could add an option to generate all the seqs with the same tree? hm, no, that probably wouldn\\'t help cause the other input files would still be different\r\n\r\n\r\n    - will need to deal with productive and out-of-frame seqs separately, i.e. different parameters\r\n    - disallow stop codons, out of frame and frame-shifted rearrangements in recombinator\r\n    - do I really want to apply the gene choice prob in waterer?\r\n    - print a warning when the kbounds we pass to the hmm don\\'t include the true one (and same thing for the gene versions)\r\n    - optimization\r\n      - wow, switching from passing seqs by reference to value really slowed it down -- need to go through Viterbi() and Forward() and see if there\\'s any other call-by-values I can remove\r\n      - would it be faster with STATE_MAX less than 1024?\r\n        - for k_v --> k_v + 1, don\\'t recalculate the whole table\r\n      - run performance profiling\r\n      - adding the gobbledygook states seems to have *really* slowed it down (EDIT oh, wait, that was just removing the gcc optimization options)\r\n      - hmm structure optimization\r\n        - it seems like I should be able to take advantage of the fact that all my hmms are super linear, i.e. the matrix of possible transitions is very sparse\r\n        - implement banding? I think I have this listed below but without using the word 'banding'\r\n      - try pairwise s-w for preclustering (all against all -- align against each *other* using sw)\r\n    - I should really be able to construct the denominator in P(A,B) / (P(A) P(B)) from the numerator without recalculating much, right?\r\n      - blast instead of s-w?\r\n      - when we\\'re doing pairs, it seems there should be some optimizations due to the fact we don\\'t need to actually identify the gene versions, but only partition the sequences (EDIT wait, what?)\r\n      - alleles: save chunks of dp tables and reuse \\'em\r\n    - accuracy improvement\r\n      - play around with s-w match/mismatch scores (match was 3[:1], just changed to 2[:1]... not sure what\\'s best. It\\'ll depend on the expected level of mutation. *sigh*)\r\n      - the choices we make about which is the best reconstruction near the d/insertions is very dependent on how much mutation we think occurred\r\n        - so try to use the amount of mutation in v to inform this decision (?)\r\n        - i.e., calculate the within-sequence correlation between V mutation and D/insertion mutation\r\n    - clustering\r\n      - connor\\'s spectral decomposition sorting\r\n      - use an N-HMM instead of a pair-HMM plus pairscore clustering (do some heuristic preclustering, then for each of these clusters, use the n-hmm viterbi path, and cluster on these)\r\n      - neighbor-joining\r\n      - transitivity:\r\n        - rather than assuming transitivity in clustering, couldn\\'t I use the extra information to improve clustering?\r\n            (NOTE this is roughly equivalent to representing an existing cluster by its viterbi path. hm, with mutations or not?)\r\n\r\n"}}
{"actor":{"display_login":"psathyrella"}}