-
Notifications
You must be signed in to change notification settings - Fork 30
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
Complete documentation / help / unit tests for SMC #215
Comments
HI Matthias, OK, for the moment I have deprecated resampling, and with the assumption that resamplingSteps can control for that. About your comments:
OK, but I think I would like to keep the option to run a non-adaptive sampler, I will try to code a switch
Those were introduced by you, I guess for a previous version of the sampler before we switched to the adaptive version? Not sure, we could erase this. Alternatively, I think it would be nice to be able to provide a vector of exponents. If we make a switch for adaptive betas or not (via iterations) we could also provide the option to provide expontens. So, I'm thinking of a syntax such as iterations = "adaptive" (either "adaptive", or number) and if iterations is a number, we could allow a vector of exponents. the lastResample I don't know - maybe it's not necessary. What was the sense of this? Also, what I noted is that the resampling / mutate word choice problem is still in there in the help. What I mean is - should better be called mutationSteps? |
Also, I wonder if we should put this block in a list mutate.control or so, as the use of the parameters changes between DE and Metropolis mutations, right? What I'm thinking is a syntax such as mutate.control = createMutateControl(method = xx, scaling = xx) similar to what is done in the regression packages with glmerControl etc. |
Regarding the arguments "exponents" and "lastResample": this is correct - they were introduced by me, but are no longer used in the current version. If we decide to allow a non-adaptive version, I think that your suggestion (iterations can be specified as a number, and in that case a vector of exponents can be given) makes sense. I wonder what the value of such an option would be, though. The argument "lastResample" was used in a previous version (by me), which was not yet adaptive. In that version, not every iteration contained a mutate step - only when the effective sample size was past the threshold. There was sometimes the issue of low particle diversity at the end of the sampling process. Therefore, this argument gives the possibility to force a mutate step on the last lastResample iterations. I agree regarding the wording - "mutate" or "mutation" would be consistent with the wording we use in the paper. Regarding the mutate control parameters, this makes sense to me. |
Hi @mspeich , fyi - the code for the paper is in branch SMC, in branch SMC-Merge I have started to integrate the new SMC in the general environment, including the rumMCMC function. I have also tried to complete the help, but it would be good to have a second eye on that before merging in the main branch.
So, @mspeich, if you have any time to spare, could you have a look at the help of the SMC function, and see in particular if the parameters are correctly explained. At the moment I don't think the descriptions are fully self-explenatory, they are more like "scaling factor for proposal", but a user should have guidance how to set the parameters, e.g. "decrease when particle degeneracy is detected".
Also, it would be good to extend the help text to the insight we have from the paper, and possibly add some more targeted examples to highlight the different options in the example file, which can be found in inst/examples.
I will concentrate on (unit) testing of the SMC in the wider framework, i.e. if everything integrates and so on. If that is done, we could merge in to master and push to CRAN.
The text was updated successfully, but these errors were encountered: