If I have multiple MCMC samplers and multiple step methods more or less as you suggested, and one of the step methods updates its self.stochastics will this interfere at all with the other step methods in the other MCMC objects?
Is there an easy way to copy a collection of stochastics for something like this?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "PyMC" group.
To post to this group, send email to py...@googlegroups.com
To unsubscribe from this group, send email to pymc+uns...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/pymc?hl=en
-~----------~----~----~----~------~----~------~--~---
--
You received this message because you are subscribed to the Google Groups "PyMC" group.
To post to this group, send email to py...@googlegroups.com.
To unsubscribe from this group, send email to pymc+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pymc?hl=en.
On Fri, Dec 18, 2009 at 4:21 AM, John Salvatier
<jsal...@u.washington.edu> wrote:
> I do have a question: have the PyMC developers considered making multiple
> chains a more fundamental part of PyMC? I am under the impression that
> multiple chains are also useful for assessing convergence and ensuring that
> the whole space is explored.
Could you be more specific about what you have in mind?
Anand
> --
>
> You received this message because you are subscribed to the Google Groups
> "PyMC" group.
> To post to this group, send email to py...@googlegroups.com.
> To unsubscribe from this group, send email to
> pymc+uns...@googlegroups.com.
> For more options, visit this group at
I have built a prototype sampler that relies on multiple interdependent chains and Differential Evolution based on "DREAM" (link) (DREAM eliminates the need for tuning and handles multiple modes well) for PyMC. I took Anand Patil's design advice to have an object that contains several MCMC objects which contain a step method, but this makes it work outside of the PyMC framework, since you can't just pass a step method to the normal MCMC object and as Anand Patil suggested, the user must implement a model generating function. If anyone wants to look at it I can send it along.
--
You received this message because you are subscribed to the Google Groups "PyMC" group.
To post to this group, send email to py...@googlegroups.com.For more options, visit this group at http://groups.google.com/group/pymc?hl=en.
To unsubscribe from this group, send email to pymc+uns...@googlegroups.com.
On Sat, Dec 19, 2009 at 5:39 AM, John Salvatier <jsalv...@gmail.com> wrote:
> Anand:
> I mean having each stochastic be capable of keeping track of multiple
> positions at once, so perhaps instead of assigning proposals to
> stochastic.value you would assign to stochastic.value[i] and likewise get
> the logp from logp_plus_loglike[i] and reject by .revert(i). Does that make
> sense?
Absolutely. However, the 'each variable has one state' design decision
is pretty entrenched. If the people interested in multiple chains/
multiple processors find that it's a deal-breaker I suppose we could
look at removing it, but my feeling at the moment is it's not going to
be a noticeable problem for concurrency over and above the GIL and
Python's inherent mutability.
A less-disruptive alternative would be to work toward making the
variable objects lighter, simpler and easier to 'copy'. We're headed
down that path in 2.1 by deprecating
M.x.trace()
in favor of
M.trace('x')
and it wouldn't be too hard to delay computation of things like the
Markov blankets & even the children to 'fitting time' and make them
attributes of models rather than variables.
I'm looking forward to having a look at your code, but most likely
won't get to it until the new year.
Cheers,
Anand