Skip to content

CategoricalGibbsMetropolis is slower than the older ElemwiseCategoricalStep #1563

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

Closed
Anjum48 opened this issue Nov 29, 2016 · 9 comments
Closed

Comments

@Anjum48
Copy link
Contributor

Anjum48 commented Nov 29, 2016

Looking at Austin Rochford's Dirichlet process mixture model which used the older ElemwiseCategoricalStep, it looks 20,000 iterations took just over 2 minutes.

Comparing to the same example in the docs which uses the newer CategoricalGibbsMetropolis, the same number of iterations takes over 14 minutes.

Does anyone know why there is such an increase in run time and if there's a way to make it faster? I've just updated my code (with the new step method) with uses the same model but on much larger data sets, and what used to take a few days to run now looks like it might span weeks :(

@twiecki
Copy link
Member

twiecki commented Nov 30, 2016

That's unfortunate. It's probably related to the Python loop where each element is proposed and accepted individually, rather than all at once like the previous Elemwise did (did we remove that sampler? Why not still use that?). Maybe there's a way to theanoize that loop or we bring back the older one as an alternative.

@Anjum48
Copy link
Contributor Author

Anjum48 commented Nov 30, 2016

It looks like ElemwiseCategorical seems to do the trick however there is a warning saying it's depreciated

@ozankabak
Copy link
Contributor

I agree with Thomas, it probably has to do with the Python loop. BTW, ElemwiseCategorical does not support various operations (e.g. indexing), hence the message. But this is a good indication that it should be kept around until CategoricalGibbsMetropolis's performance catches up.

@twiecki
Copy link
Member

twiecki commented Dec 2, 2016

Actually it's probably not just the python loop, but the fact that logp gets evaluated N times for a vector of length N, rather than just once. There's no way around that for Gibbs but it does suggest that we should keep ElemwiseCategorical, but maybe rename it to CategoricalMetropolis for consistency.

@rahuldave
Copy link

It is indeed super-slower. It makes doing clustering Models nigh impossible. See this screenshot for time differences on the old faithful waiting times 2 component gaussian mixture model..

@twiecki
Copy link
Member

twiecki commented Apr 13, 2017

I wonder if a theano.scan could speed the loop up because it could allow theano to cache the rest of the graph.

@rahuldave Can you just use ElemwiseCategorical? The best solution would be to use a marginalize the cluster assignments: http://pymc-devs.github.io/pymc3/notebooks/marginalized_gaussian_mixture_model.html

@rahuldave
Copy link

Yes thats what I did. But perhaps the competences ought to currently be changed? Marginalizing, both explicitly and implicitly using the pymc API is part of tomorrows lab :-)

@twiecki
Copy link
Member

twiecki commented Apr 14, 2017 via email

@twiecki
Copy link
Member

twiecki commented Apr 15, 2017

See #2037.

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

6 participants