Merge 3.1 branch

[twiecki]

No description provided.

[ferrine]

in 7f95425 I fix cyclic import, you can do the same

[twiecki]

Thanks @ferrine. Not sure why the exact sample test for HMC is failing here. @ColCarroll, ideas?

[ColCarroll]

I feel like I've seen this exact failure before -- in the travis logs the traces look exactly the same (though I guess only the first 23 entries are actually the same). I can look more closely later, but probably need to print the full traces.

[twiecki]

Most of them differ by E-20, but I saw one differing on order of .1.

[fonnesbeck]

If we are going to add a pymc3.models submodule, then we need to reconcile that with pymc3.model. We should not have both.

Also, we have things like timeseries, which is just another type of model, but it is not in models. This requires more discussion and consideration, but I don't think having a generic models submodule is the best way to go.

[ferrine]

Can we try setuptools.find_packages() in setup script after fixing hmc? There were some issues with missing modules, they are easy to fix but setuptools suggest a better solution.

[ColCarroll]

Ah, update on HMC -- I looked into it for a while, and took a larger sample from a working SHA and HEAD. The larger samples had the same behavior: they'd be equal for a while, then all of a sudden be different, the converge again, though there was no readily apparent pattern in how different they were. It is interesting because

• even though HMC shares machinery with NUTS, only HMC is failing,
• the momentum samples remain exactly the same
• somehow the traces reconverge

The algorithm still seems fine -- my working theory is that the calls to the numpy random number generator are getting evaluated in a different order sometimes, or some other function is making a draw from the RNG. I'm not against replacing the test with the current trace, but I'll probably keep looking at this if only because I'm intrigued now.

[ColCarroll]

In particular, I think the other call to an RNG is for the metropolis acceptance step, so it seems like that must be it...

[twiecki]

@ColCarroll If that's the issue, does it suggest that the Metropolis accept does not use the correct seed? How do we fix it?

[ColCarroll]

It'll take more testing to figure this out -- everything uses numpy.random, so the seed is set right. What I suspect happens is, roughly:

On master:

for step in steps:
    hmc_sample_momentum()
    hmc_metropolis_accept()
    # occasionally
    something_else_draw_sample()

In current branch:

On master:

for step in steps:
    hmc_sample_momentum()
    # occasionally
    something_else_draw_sample()
    hmc_metropolis_accept()

This would explain why it is usually in sync, but goes into and out of sync.

[twiecki]

OK, so if we change the stored samples we should be good?

[ColCarroll]

Yeah, seems like. The statistical check on HMC still passes. Will rest easier if I knew why it changed, though.

…

On Tue, Jan 17, 2017, 10:05 AM Thomas Wiecki ***@***.***> wrote: OK, so if we change the stored samples we should be good? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1658 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACMHEHdNfoDVphTKxhQrF2sAOnduDKalks5rTNipgaJpZM4Lebbh> .

[twiecki]

@ferrine Can you push the update? Maybe we can decouple the easy resting from making travis happy. At least you looked deep enough that there aren't clear bugs.

[ferrine]

I've merged my PR with find_packages into 3.1 but it did not appear here. Hmm, I did something wrong?
UPD: it appeared

[ColCarroll]

wowza -- after some close checking, there is a transposed negative sign in the hmc sampler. Since hmc rarely rejects samples, the differences were very close. I'll add that change in.

[twiecki]

@ColCarroll Wow, those tests really paid off here!

[twiecki]

OK, I'm going to merge this so that we get out of this limbo.

[fonnesbeck]

Nice work guys!