Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upPaper comparison #105
Paper comparison #105
Conversation
This comment has been minimized.
This comment has been minimized.
|
I compared the paper data to the LDATS data. It looks like LDATS rodent table is the raw table (not adjusted for incomplete censuses). For now I'm working with the adjusted table, to avoid artificially low abundances for incompletely-trapped periods. |
LDATS chooses 6 topics but the paper had 4.
This comment has been minimized.
This comment has been minimized.
|
@juniperlsimonis, I know we’ve talked about the LDA model selection criterion and we changed it from the paper to LDATS. If I recall correctly, the paper used AIC and this summer we switched to AICc. Do you think that’s why they’re giving different #’s of topics? I looked into testing that theory by running LDATS::LDA_select but switching to AIC. I think I need to change the
When we were doing this in LDA-kratplots I think
So - tl;dr - I’m wondering if you can help with
|
This comment has been minimized.
This comment has been minimized.
|
thanks for digging into this!
which means you can either create a control list object ( i'm going to create a new comment to paste in some slack conversations about your 3rd question |
This comment has been minimized.
This comment has been minimized.
|
ok, so for the comparison, there was a fair amount of back-and-forth in slack messages about this, and it's kind of obnoxious that i can't just add you in to that thread (as far as i can tell), so this is just going to be me pasting in a bunch of stuff. tl;dr, the answer has to do with counting the number of parameters to correct the logLik with in the calculation of AIC. the version in the paper counted by hand, and over counted (included the gamma parameters in the count). the version in LDATS counts using what's generated by the Me: The marginal likelihood doesn’t inherently include a complexity penalty, it’s just the likelihood with some parameters integrated out. And the output of While the marginal likelihood doesn’t have a complexity penalty itself, however, the approximated likelihood that’s returned by the variational EM is necessarily lower than the “true” marginal likelihood (the likelihood of the model without the variation parameters), so I guess you could consider it in some senses “penalized”. However, the degree of difference ("penalty") between the true likelihood and the variational approximation is the KL divergence between the variational distribution used and the true distribution. Notably here, the “true” distribution is not the unknown truth as it is during standard model comparisons (wherein, it’s a constant across the models). Rather, it is “the model without all of the variational parameters”, which does change across the different models (number of topics) in the VEM method. Thus, while there is a level of “penalizing” via the variational approximation the likelihood, that’s actually not a bad thing, but it’s only a partial accounting for the complexity of the model and not sufficient to compare the resulting models when the number of topics change. To fully penalize for the model complexity in comparison across models of different numbers of topics, the variational approximation of the lower bound of the marginal likelihood needs to be corrected for the remaining among-model variation in the number of parameters. You all approached the remaining correction by penalizing the models for the full suite of variational parameters (rather than just those remaining after the variational approximation), which is an excessive correction. However, you all didn’t account for the relative small sample size, which works in the opposite direction (leads to over complex models, i.e. isn’t a stringent enough correction). It looks like the correction for the number of parameters is more impactful than the correction for the number of data points, so it’s likely that you all are more stringent than necessary/ideal overall. For reference, a selection procedure that only penalizes for the remaining parameters and includes a small sample size correction picks 5 topics. Dave
Morgan Hi everyone. This is great. Thanks to both of you for working through this. Looks like things are exactly in the state that we thought when we made the manuscript changes and wrote the letter to the editor. As for how to proceed, nothing in this conversation changes my mind about the best route forward. Selecting the most appropriate number of topics is an evolving area. As @Juniper Simonis pointed out in our discussions with them, what we’ve done in this manuscript is still a step forward from Valle et al. As the paper has been going through the review process, Juniper has been thinking hard about improved approaches to ours and their work highlights the shortcomings with our approach. This is what will always happen in fast moving fields – it’s just normally we wouldn’t know about it at this phase because that would probably be happening in a different lab (the awesomeness and the curse of being the lab both developing and using a tool!). Since the manuscript has already been accepted and the advances are based on Junipers work I don’t think it’s appropriate to change the analyses at this phase. My suggestion is that we continue with the original plan as implemented in the revised manuscript and letter to the editor – we have caveated our (already improved) AIC approach appropriately, we know it is at worst conservative in selecting the number of topics. Finding more topics at worst means there are more changepoints, which doesn’t alter our core message – change happens in a complicated pattern that includes multiple rapid transitions. In our next LDA paper, we will update the AIC method based on Juniper’s ongoing work on this issue. That’s my preference, the ultimate decision is up to @echriste as the lead author on this. @dave.harris are you ok with this? Dave
Morgan What's in the first paper now |
This comment has been minimized.
This comment has been minimized.
|
Ohhhh thanks! So my take-away from the slack conversations is that the 6 v. 4 outcomes, specifically, can with reasonable certainty be attributed to the differences in how the parameters are being counted (without even getting into AICc vs AIC)? If that's accurate, I'll keep going with a side-by-side comparison of changepoint with both selected LDAs. Thanks again - this is super helpful!! |
This comment has been minimized.
This comment has been minimized.
|
you're welcome! |
This comment has been minimized.
This comment has been minimized.
|
Hey @juniperlsimonis, I'm turning up an error when trying to feed
The paper LDA code generates an Interestingly, Is there a way that I've missed to make the paper LDA_VEM (look like) a LDA/LDA_set object? Thanks!! |
This comment has been minimized.
This comment has been minimized.
|
ay! good catch! so, the way to make
in place of where you did
|
5 changepoints is still the lowest-deviance
Saving the changepoint objects in the repo breaks git (?). Setting up to save them outside the repo also lets me work in other branches without getting tangled up.
I'm saving the changepoint models to my computer, because if I put them in the repo it breaks git on my computer. I'm thinking of putting the .Rds files in Dropbox or some other workaround for large files.
Paper changepoint on paper lda vs LDATS lda. At this point I find it easiest to open the image files in 'paper-changepoint-files' and put the LDATS lda ones side by side with the paper lda ones. I know this is... not ideal. Both give same #'s of changepoints (4 or 6 - 6 has lower deviance, but I'm not sure if the changepoint is to be trusted for 6 cpts?) and roughly the same locations. The LDATs LDA w/ 4 cpts has less bimodality in the 1990's than the paper LDA.
6 cpts is not, in fact, ever the best model.
start to compare ldas with adjusted/nonadjusted data store model objects in dropbox
Adjusted v. nonadjusted data frames give qualitatively but not exactly the same results with the paper LDA
confliect resolution to facilitate rebase
conflict resolution for rebasing
conflict resolution for rebasing
…re to consolidate all .Rds files into one file to load
…ssary load/rm. For the most part display rather than run code in paper-comparison vignette. Keep load/rm (unevaluated) in changepoint code, to demo memory management.
|
addresses #78 |
Here's a draft of the paper comparison vignette. Feedback would be welcome! But I'll also continue to comb through it, so no worries if it's not at the top of your list.