Skip to content
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

Open
florianhartig opened this issue Apr 21, 2021 · 3 comments
Open

Complete documentation / help / unit tests for SMC #215

florianhartig opened this issue Apr 21, 2021 · 3 comments
Assignees

Comments

@florianhartig
Copy link
Owner

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.

@florianhartig
Copy link
Owner Author

HI Matthias,

OK, for the moment I have deprecated resampling, and with the assumption that resamplingSteps can control for that.

About your comments:

iterations: wird nicht verwendet, ausser in Zeile 367 zur Berechnung von info$rejectionRate (basierend auf einer Variable rejectionRate, die nur initialisiert, aber nie geändert wird)

OK, but I think I would like to keep the option to run a non-adaptive sampler, I will try to code a switch

exponents und lastResample: werden nur verwendet, um in Zeile 256 einen resampling Step auszulösen. Das sollte eigentlich nie greifen, solange exponents den Wert NULL hat (default). Zudem denke ich, dass es keinen Sinn macht, einen Vektor für exponents als Argument anzugeben (nicht kompatibel mit dem gewählten adaptiven Jeremiah-Verfahren).

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

image

better be called mutationSteps?

@florianhartig
Copy link
Owner Author

Also, I wonder if we should put this block

image

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.

@mspeich
Copy link
Collaborator

mspeich commented Jun 11, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants