FAIL if initialized with ANY walkers at -Inf about emcee

[ipashchenko]

Why is this an issue? "Infinite" walker can get out of the "infinity" at the next step if some walkers in ensemble are "finite". Doesn't it raise the problem with random initialization of walkers in the case of the prior that has some regions of zero probability (-inf for ln_p) because of e.g. constraints imposed by user?

[dstndstn]

A walker that has a parameter value set to Inf cannot escape Inf,
because the "stretch move" that the ensemble sampler is a linear combination of
its current position and the position of some other sample; p_new = p_old +
(p_other - p_old) * alpha. If p_old is Inf, p_new is Inf.

On Fri, 22 Mar 2013, Ilya wrote:

Why is this an issue? "Infinite" walker can get out of the "infinity" at the next step if some walkers in ensemble are "finite". Doesn't
it raise the problem with random initialization of walkers in the case of the prior that has some regions of zero probability (-inf for
ln_p) because of e.g. constraints imposed by user?

—
Reply to this email directly or view it on GitHub.[nYCuMxH-c8n4yM9OOnIktOAQKGaJkMnBIsgEBjMFJrGn5qeeqwPOxIXEhSBeLVFd.gif]

[ipashchenko]

Thanks for the detailed answer, but are we not talking about the logarithm of the probability density at some point of parameter space ("walker") - ln_p? If ln_p for some walker is -inf (zero prob.) then after "stretch move" it could be finite. I think you're talking about infinite values ​​of the parameters themselves (coordinates in parameter space) but the issue is about probabilities of them.

[dstndstn]

Oh, sorry, I clearly didn't read the original issue!

You are right, a walker with lnprob = -inf but finite params could get out with a stretch move.

(If lnprob = NaN, on the other hand, there could be problems, since NaN comparisons are strange; (100 > NaN) = False.)

Is there a test case (or hey, a unit test that fails) demonstrating this issue? If not I would close it.

[dfm]

Yeah this looks right... in practice, things seem to go to hell whenever I do this but I'll do some tests to try to figure out what's going on.

I'm going to keep this open for now in order to remember.

[ipashchenko]

If lnprob = NaN, on the other hand, there could be problems, since NaN comparisons are strange; (100 > NaN) = >False.

Yes, but it turns that any proposal with "newlnpob" which equals NaN leads to the rejection of that proposal because acceptance is the result of the comparison. And comparisons with NaN return False. Such cases only lower the acceptance ratio. It seems that the problem is when walker is initialized with lnprob0 = NaN. Then because of above every its proposal will be rejected.

[davidwhogg]

I agree with @ipashchenko that this shouldn't be a problem. I think the problem may be that a whole slew of walkers at -Inf can walk very far away with constant acceptances. I think the rules should be:

if walker starts at finite lnp and is proposed at -Inf, reject.

if walker starts at -Inf and is proposed at finite, accept.

If walker starts at -Inf and is proposed at -Inf, REJECT.

This latter point might not be true right now, right? @dfm if you agree, then issue this.

[ipashchenko]

This latter point might not be true right now, right?

It seems that walker that has lnprob=-Inf and is proposed to -Inf is rejected now. Because "lnpdiff" for such walker is NaN. So "accept" is the result of comparison "lnpdiff > some rand stuff". And this is false.

[davidwhogg]

If all that is true, then I don't see why in practice we wedge when some initial walkers are at -Inf

[ipashchenko]

It would be interesting to see the example. By the way, unit test has appeared in my pull request that fails if walker is initialized with lnprob0 = NaN. Such "dead" walker has zero acceptance fraction.

[davidwhogg]

In general we should fail if any lnp is ever NaN.

@dfm feel free to close this issue and open (or not) others related.

[dfm]

The sampler now raises a ValueError if lnprob ever returns np.nan. I think that this is probably the right behaviour... and objections?

@ipashchenko: Thanks for you unit test... I've merged it.

[ipashchenko]

It seems that any proposal with "newlnpob" which equals NaN leads to the rejection of that proposal. This current commit will raise ValueError exception in such case. I think it is not necessary (because such proposal is rejected anyway so it is not a problem for sampling). Such cases of newlnprob=NaN should be rare for healthy callable densities. It shouldn't affect the acceptance fraction seriously. But it will be a real problem if some walker is initialized with lnprob0=NaN (this walker will have zero acceptance fraction). Thus I think exception should be raised not in ensemble._get_lnprob(), but in ensemble.sample() while checking if initial values of lnprob are provided. More specifically, i think exception should be raised if argument lnprob0 contains NaN entries or lnprob0 is calculated and contains NaN entries. Somewhere:

    # If the initial log-probabilities were not provided, calculate them
    # now.
    lnprob = lnprob0
    blobs = blobs0
    if lnprob is None:
        lnprob, blobs = self._get_lnprob(p)

Well, it puts some responsibility to user to control acceptance fractions and callable density (if callable density often returns NaN). What do you think about it?

[dfm]

Sure. I'll add a check at the beginning of sampling... that's a good idea. I do, however, think that it's still reasonable to leave the check in that I added because something has gone wrong if your log-probability is np.nan. The user can choose to check for NaNs themselves if they're getting too many ValueErrors but I think that it's better to not let it pass silently.

[ipashchenko]

Yes, you are right - current realisation is much safer.

[dfm]

I think you'll be happy with 4ec12a4. It should address the issue raised in your previous comment.