Hey Andy - happy new years!
So should VBGMM and DPGMM's precisions_ attribute be changed to covars_ like in gmm.py?
Also, the docstrings read:

`precisions_` : array
        Precision (inverse covariance) parameters for each mixture
        component.  The shape depends on `covariance_type`

and

`covars_` : array
        Covariance parameters for each mixture component.  The shape
        depends on `covariance_type`

So different

and the _get_covars function needs a better docstring and made public?

Hey Jaques. Happy new year to you, too!

hum. Ok so they are differnent and shouldn't be renamed. But why are they stored one way in one estimator and the other way in the other estimators?

But yeah, I'd be very much in favor of making the function public and adding a proper docstring. And see how that fits into the general interface.

hum. Ok so they are differnent and shouldn't be renamed. But why are they stored one way in one estimator and the >other way in the other estimators?

That I'm not sure of.. Perhaps it works better for dpgmm to use it like that, as opposed to the gmm way.. I'd have to read into it further.. just a guess for now :)

Some formulations of GMMs like to use precision instead of covariance, or at least my teacher (who used Bishop) tended to formulate things with precision instead of covariance, including GMM.

Would a stopgap fix for this be to have both covars_ and precision_ available for each? Or maybe add a _get_precision() function to both (and a _get_covars() to the ones which need it), but keep them private for now - I can see situations where one or the other might be more useful/more stable

gmm is deprecated