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 :-/

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.

So the sample method should probably be rewritten in the subclass.
@esheldon do you want to have a go?

I am interested but I don't have much time over the next couple of weeks.

Looking at this, I think the sampling code is the easy part. We just need
to have the variances present in the object, correct?

More of an issue is that the variances produced by get_covar are not
correct. I played with it some more and I'm pretty sure that they are
actually wrong and it isn't just a misinterpretation. I don't understand
the algorithm so I'm not sure I could help.

-e

On Wed, Jan 30, 2013 at 3:24 AM, Gael Varoquaux [email protected]:

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.

So the sample method should probably be rewritten in the subclass.
@esheldon do you want to have a go?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1637#issuecomment-12878997.

Erin Scott Sheldon
Brookhaven National Laboratory erin dot sheldon at gmail dot com

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

It just inverts the precisions

def _get_covars(self):
    return [pinvh(c) for c in self._get_precisions()]

-e

On Wed, Jan 30, 2013 at 9:44 AM, Andreas Mueller
[email protected] wrote:

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

—
Reply to this email directly or view it on GitHub.

Erin Scott Sheldon
Brookhaven National Laboratory erin dot sheldon at gmail dot com

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

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

x=numpy.random.randn(1000)
gmm=mixture.DPGMM(n_components=1)
gmm.fit(x.reshape(1000,1))
gmm.precs_
[array([[ 0.49380025]])]
gmm._get_covars()
[array([[ 2.02511035]])]

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 😄 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.

x=numpy.random.randn(1000)
gmm=mixture.DPGMM(n_components=1)
gmm.fit(x.reshape(1000,1))
gmm.precs_
[array([[ 0.49380025]])]
gmm._get_covars()
[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
0.49380025142827405

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

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

Closing: the new Dirichlet process GMM re-write has been merged in master. Its sample method is properly tested.