-
Notifications
You must be signed in to change notification settings - Fork 3
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
How are we going to optimize model parameters? #44
Comments
Aaron's option -- eating chinese with Connor and Erick, quantum-superposition-style. For parameter X keep a fixed number k of global parameter "tables" x_1...x_k, each particle keeps a vector of length k called V that encodes the probability it is sitting at each of the k tables. During the extension step individual particles can propose changes to V. beagle has support in calculateRootLogLikelihoods() to set arbitrary weights for rate categories and state frequency categories, I think allowing particles with shared history to have different V. Updates to V will not require a full re-peel. In between generations we can do moves that change the x_1...x_k. These will affect all particles equally and won't force us to delete shared history among particles. We will have to repeel every node in the shared history forest. |
Erick's other idea: Chinese musical chairs. There are a fixed set of k If we were clever with BEAGLE, would it save time to peel all of the On Fri, Oct 26, 2012 at 11:20 AM, Aaron Darling notifications@github.comwrote:
Frederick "Erick" Matsen, Assistant Member |
One thing I'm not sure about is what a "global" MH move looks like. Normally MH is the ratio of probs for current and proposed state for a single state. What would it look like for a population of states? Product of that ratio over all states? |
In Chinese musical chairs, when two particles with shared history move to different tables, would that require us to duplicate their shared history? |
Yes. Which motivates quantum Chinese musical chairs? On Fri, Oct 26, 2012 at 12:32 PM, Aaron Darling notifications@github.comwrote:
Frederick "Erick" Matsen, Assistant Member |
Not necessarily, quantum Chinese demands calculating likes for all tables for each node in the history all the time -- which might be more work. |
Thinking on this thread again. One further possibility occurred to me, though I'm not sure whether it's a good idea (feedback pls!): at each generation it might be possible to make an ML estimate of the gamma (or another continuous) parameters. This would work by doing something like Brent optimization, similar to what happens in FastTree. The ML parameter estimates could be used for all particles at the next generation. The result would be a sort of SMC-within-EM algorithm, with EM for continuous parameters. Possible problems include early generations being too uninformative for continuous parameter estimation and local maxima traps, and no estimates of uncertainty. The potential advantage is greater efficiency by preserving shared particle history. This approach may be quite similar to what Connor was suggesting, but without the MH steps? |
What bothers me about this is that all of the particles are constrained to On Mon, Dec 10, 2012 at 3:24 PM, Aaron Darling notifications@github.comwrote:
Frederick "Erick" Matsen, Assistant Member |
yet another idea: a hierarchical prior on rates. |
^--------- this also requires computing lots of finite time transition matrices with beagle, unless we do it chinese restaurant style. |
Er, this idea scares me a little because:
|
Wouldn't the degree of variance in early particles depend on how tight the prior is? If the prior is tight then it seems like it leaves less room for rate parameters to stray. Of course, next question is how do you set a tight prior? Maybe hyperpriors would help? I agree that reporting branch-wise rate parameters would not be terribly helpful, but in a hierarchical Bayes model maybe these could be summarized over all branches to a posterior on the prior's parameters. That would be a single global rate estimate. |
Right, I don't know how to set a tight prior without setting the wrong On Mon, Dec 10, 2012 at 4:54 PM, Aaron Darling notifications@github.comwrote:
Frederick "Erick" Matsen, Assistant Member |
Connor's option-- do MH moves that impact all particles at once.
Erick's option-- for each particle with some probability, propose a MH move for the rate parameters. This duplicates the particle when accepted.
The text was updated successfully, but these errors were encountered: