Skip to main content
Corrected spelling errors
Source Link
jbowman
  • 41k
  • 8
  • 78
  • 138

You have several nice, more-or-less simple, options. Your uniform prior helps make them simpler.

Option 1: Independence sampler. You can just set your proposal distribution equal to a uniform distribution over the unit square, which ensures that samples won't fall outside the restricted zone, as you call it. Potential downside: if the posterior is concentrated in a very small region of the unit square, you may have a very low acceptance rate. OTOH, it's hard to generate random numbers faster than from a U(0,1) distribution. Potential upside: less work for you.

Option 2: Transform your parameters to something that isn't bounded, make proposals for the transformed parameters, then transform the parameters back for use in the likelihood functions. Note that in this case the prior is going to be on the transformed parameters, because that's what you're making proposals for, so you'll have to mess with the Jacobian of the transform to get the new prior. For your analysis, of course, you'll transform the MCMC-generated parameter random numbers back to the original parameters. Potential downside: more initial work for you. Pptential Potential upside: better acceptance rate for your proposals.

Option 3: Construct a proposal distribution other than an independence sampler that is on the unit square. This allows you to keep your uniform prior, but at the cost of greater complexity when calculating the proposal probabilities. An example of this, letting $x$ be the current value of one of your parameters, would be a Beta distribution with parameters $(nx, n(1-x))$. The larger $n$ is, the more concentrated your proposal will be around the current value. Potential downside: more initial work for you. Pptential Potential upside: better acceptance rate for your proposals - but if you make $n$ too large, and move near to a corner, you might wind up making lots of small moves in the corner before getting out.

Option 4: Just reject any proposals that fall outside the unit square (Xian's half-hearted suggestion). Note that this is not the same as just generating another proposal; in this case you are rejecting the proposal, which means your next value for the parameter is the same as the current value for the parameter. This works because it's what would happen if you had a zero prior probability for some region of your parameter space and generated a random number that fell in that region. Potential downside: if you get near a corner, you may have a low acceptance probability and get stuck for a while. Potential upside: less work for you.

Option 5: Create an extended problem on the plane which, on the unit square, is the same as the actual problem you face, do everything right, then, when post-processing the results of the MCMC sampling, throw out all the samples outside of the unit square. Potential upside: If it's very easy to create that extended problem, it may be less work for you. Potential downside: if the Markov chain wanders off somewhere outside the unit square for a while, you may have, in effect, horrible acceptance probabilities, as you will throw out most of your samples.

No doubt there are other options, I'd be interested to see what other people suggest!

The difference between 2 and 3 is to some extent conceptual, although with real implications for what you actually do. I'd probably go with 3, as I'd just let R tell me what the proposal probabilities are (if I'm programming in R) and the amount of extra effort, aside from some tuning of the proposal distribution parameter $n$, looks small to me. If I was using JAGS or BUGS, of course, that would be a whole different matter, since those tools handle their own proposals.

You have several nice, more-or-less simple, options. Your uniform prior helps make them simpler.

Option 1: Independence sampler. You can just set your proposal distribution equal to a uniform distribution over the unit square, which ensures that samples won't fall outside the restricted zone, as you call it. Potential downside: if the posterior is concentrated in a very small region of the unit square, you may have a very low acceptance rate. OTOH, it's hard to generate random numbers faster than from a U(0,1) distribution. Potential upside: less work for you.

Option 2: Transform your parameters to something that isn't bounded, make proposals for the transformed parameters, then transform the parameters back for use in the likelihood functions. Note that in this case the prior is going to be on the transformed parameters, because that's what you're making proposals for, so you'll have to mess with the Jacobian of the transform to get the new prior. For your analysis, of course, you'll transform the MCMC-generated parameter random numbers back to the original parameters. Potential downside: more initial work for you. Pptential upside: better acceptance rate for your proposals.

Option 3: Construct a proposal distribution other than an independence sampler that is on the unit square. This allows you to keep your uniform prior, but at the cost of greater complexity when calculating the proposal probabilities. An example of this, letting $x$ be the current value of one of your parameters, would be a Beta distribution with parameters $(nx, n(1-x))$. The larger $n$ is, the more concentrated your proposal will be around the current value. Potential downside: more initial work for you. Pptential upside: better acceptance rate for your proposals - but if you make $n$ too large, and move near to a corner, you might wind up making lots of small moves in the corner before getting out.

Option 4: Just reject any proposals that fall outside the unit square (Xian's half-hearted suggestion). Note that this is not the same as just generating another proposal; in this case you are rejecting the proposal, which means your next value for the parameter is the same as the current value for the parameter. This works because it's what would happen if you had a zero prior probability for some region of your parameter space and generated a random number that fell in that region. Potential downside: if you get near a corner, you may have a low acceptance probability and get stuck for a while. Potential upside: less work for you.

Option 5: Create an extended problem on the plane which, on the unit square, is the same as the actual problem you face, do everything right, then, when post-processing the results of the MCMC sampling, throw out all the samples outside of the unit square. Potential upside: If it's very easy to create that extended problem, it may be less work for you. Potential downside: if the Markov chain wanders off somewhere outside the unit square for a while, you may have, in effect, horrible acceptance probabilities, as you will throw out most of your samples.

No doubt there are other options, I'd be interested to see what other people suggest!

The difference between 2 and 3 is to some extent conceptual, although with real implications for what you actually do. I'd probably go with 3, as I'd just let R tell me what the proposal probabilities are (if I'm programming in R) and the amount of extra effort, aside from some tuning of the proposal distribution parameter $n$, looks small to me. If I was using JAGS or BUGS, of course, that would be a whole different matter, since those tools handle their own proposals.

You have several nice, more-or-less simple, options. Your uniform prior helps make them simpler.

Option 1: Independence sampler. You can just set your proposal distribution equal to a uniform distribution over the unit square, which ensures that samples won't fall outside the restricted zone, as you call it. Potential downside: if the posterior is concentrated in a very small region of the unit square, you may have a very low acceptance rate. OTOH, it's hard to generate random numbers faster than from a U(0,1) distribution. Potential upside: less work for you.

Option 2: Transform your parameters to something that isn't bounded, make proposals for the transformed parameters, then transform the parameters back for use in the likelihood functions. Note that in this case the prior is going to be on the transformed parameters, because that's what you're making proposals for, so you'll have to mess with the Jacobian of the transform to get the new prior. For your analysis, of course, you'll transform the MCMC-generated parameter random numbers back to the original parameters. Potential downside: more initial work for you. Potential upside: better acceptance rate for your proposals.

Option 3: Construct a proposal distribution other than an independence sampler that is on the unit square. This allows you to keep your uniform prior, but at the cost of greater complexity when calculating the proposal probabilities. An example of this, letting $x$ be the current value of one of your parameters, would be a Beta distribution with parameters $(nx, n(1-x))$. The larger $n$ is, the more concentrated your proposal will be around the current value. Potential downside: more initial work for you. Potential upside: better acceptance rate for your proposals - but if you make $n$ too large, and move near to a corner, you might wind up making lots of small moves in the corner before getting out.

Option 4: Just reject any proposals that fall outside the unit square (Xian's half-hearted suggestion). Note that this is not the same as just generating another proposal; in this case you are rejecting the proposal, which means your next value for the parameter is the same as the current value for the parameter. This works because it's what would happen if you had a zero prior probability for some region of your parameter space and generated a random number that fell in that region. Potential downside: if you get near a corner, you may have a low acceptance probability and get stuck for a while. Potential upside: less work for you.

Option 5: Create an extended problem on the plane which, on the unit square, is the same as the actual problem you face, do everything right, then, when post-processing the results of the MCMC sampling, throw out all the samples outside of the unit square. Potential upside: If it's very easy to create that extended problem, it may be less work for you. Potential downside: if the Markov chain wanders off somewhere outside the unit square for a while, you may have, in effect, horrible acceptance probabilities, as you will throw out most of your samples.

No doubt there are other options, I'd be interested to see what other people suggest!

The difference between 2 and 3 is to some extent conceptual, although with real implications for what you actually do. I'd probably go with 3, as I'd just let R tell me what the proposal probabilities are (if I'm programming in R) and the amount of extra effort, aside from some tuning of the proposal distribution parameter $n$, looks small to me. If I was using JAGS or BUGS, of course, that would be a whole different matter, since those tools handle their own proposals.

Source Link
jbowman
  • 41k
  • 8
  • 78
  • 138

You have several nice, more-or-less simple, options. Your uniform prior helps make them simpler.

Option 1: Independence sampler. You can just set your proposal distribution equal to a uniform distribution over the unit square, which ensures that samples won't fall outside the restricted zone, as you call it. Potential downside: if the posterior is concentrated in a very small region of the unit square, you may have a very low acceptance rate. OTOH, it's hard to generate random numbers faster than from a U(0,1) distribution. Potential upside: less work for you.

Option 2: Transform your parameters to something that isn't bounded, make proposals for the transformed parameters, then transform the parameters back for use in the likelihood functions. Note that in this case the prior is going to be on the transformed parameters, because that's what you're making proposals for, so you'll have to mess with the Jacobian of the transform to get the new prior. For your analysis, of course, you'll transform the MCMC-generated parameter random numbers back to the original parameters. Potential downside: more initial work for you. Pptential upside: better acceptance rate for your proposals.

Option 3: Construct a proposal distribution other than an independence sampler that is on the unit square. This allows you to keep your uniform prior, but at the cost of greater complexity when calculating the proposal probabilities. An example of this, letting $x$ be the current value of one of your parameters, would be a Beta distribution with parameters $(nx, n(1-x))$. The larger $n$ is, the more concentrated your proposal will be around the current value. Potential downside: more initial work for you. Pptential upside: better acceptance rate for your proposals - but if you make $n$ too large, and move near to a corner, you might wind up making lots of small moves in the corner before getting out.

Option 4: Just reject any proposals that fall outside the unit square (Xian's half-hearted suggestion). Note that this is not the same as just generating another proposal; in this case you are rejecting the proposal, which means your next value for the parameter is the same as the current value for the parameter. This works because it's what would happen if you had a zero prior probability for some region of your parameter space and generated a random number that fell in that region. Potential downside: if you get near a corner, you may have a low acceptance probability and get stuck for a while. Potential upside: less work for you.

Option 5: Create an extended problem on the plane which, on the unit square, is the same as the actual problem you face, do everything right, then, when post-processing the results of the MCMC sampling, throw out all the samples outside of the unit square. Potential upside: If it's very easy to create that extended problem, it may be less work for you. Potential downside: if the Markov chain wanders off somewhere outside the unit square for a while, you may have, in effect, horrible acceptance probabilities, as you will throw out most of your samples.

No doubt there are other options, I'd be interested to see what other people suggest!

The difference between 2 and 3 is to some extent conceptual, although with real implications for what you actually do. I'd probably go with 3, as I'd just let R tell me what the proposal probabilities are (if I'm programming in R) and the amount of extra effort, aside from some tuning of the proposal distribution parameter $n$, looks small to me. If I was using JAGS or BUGS, of course, that would be a whole different matter, since those tools handle their own proposals.