Skip to content


Subversion checkout URL

You can clone with
Download ZIP


dpgmm sample not working #1637

esheldon opened this Issue · 14 comments

5 participants


Hi Guys -

Trying out DPGMM to see if I can get a more stable solution. Things look good so far except for one problem.

The sample() method does not work for dpgmm. The primary reason is that sample() assumes there is a self.covars_, but this does not exist.

There is a secondary problem however. I tried using get_covars to set the covars but these covariances are not correct, perhaps because of a different convention somehow in the definitions of these covariances.

best, and thanks for the good work on sklearn,


Thanks for reporting. I'll try to have a look soon (if no one else does before me).


By the way, thanks for trying to help us with DPGMM. Maybe one good step forward would be to improve test coverage to prevent such mishaps :-/


Ok, so it seems that the sample method is inherited from GMM. I'm not sure that should be the case. the parameterization in which VBGMM and DPGMM are stored are somewhat different from GMM iirc.
It would be great if GMM and VBGMM/DPGMM had a common interface. That is not really the case now :-/


This is probably the wrong function to get the covariances. The VBGMM stores the precision values, not covariances iirc.


Ok I'll have to have a closer look. What gave you the impression they are wrong?


hm that is a bit irritating behavior, though....


The get_covars just uses precs_. I think this is an "off by two" error in VBGMM/ DPGMM. It is the same for all covariance types apparently. cc @alextp


Is there any word on this? Or a hint on how to fix it :smile: I'd love to get a sample from the DPGMM
@amueller @alextp


Looks like they are off by a factor of two, so maybe it is just definitional.

[array([[ 0.49380025]])]
[array([[ 2.02511035]])]

Maybe I'm sorely mistaken / missing something obvious, but this appears to be correct behavior to me. Precision is inverse covariance, and the covariance returned by _get_covars() is equal to the inverse precision in your example:

>>> 1 / 2.02511035

I don't see any off-by-two error here.

@amueller amueller added this to the 0.15.1 milestone

I agree with @HapeMask, I think this looks ok. I fixed it in #4182.

@amueller amueller modified the milestone: 0.16, 0.17
@amueller amueller modified the milestone: 0.18, 0.17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.