MLJ interface: fit should not mutate model fields about betaml.jl HOT 3 CLOSED

I have implemented the mixtures option in the MLJ interface as either :diag_gaussian, :full_gaussian or :spherical_gaussian.
For the rest I would prefer keep the model current approach for now.

from betaml.jl.

Hello, I have implemented deepcopy of the model initial mixtures in commit 5ea564f340c9ec9246d51eac8098e44058820ac9 so that the original model mixtures (and initial mixture prior probabilities) aren't modified in fit.

Be aware however that the check you used still wouldn't work. In Julia indeed custom types (as BetaML.Mixture) need to implement == explicitly and I didn't do it for the mixtures I defined:

struct MyStruct
    x::Int64
end
obj1 = MyStruct(1)
obj2 = MyStruct(2)
obj3 = deepcopy(obj1)

obj1 == obj2 # false
obj3 == obj2 # false

# Let's implement `==` for MyStruct: 
import Base.==
==(a::MyStruct,b::MyStruct) = a.x == a.x

obj1 == obj2 # now it's true
obj3 == obj2 # now it's true

from betaml.jl.

Yes, you are right, I had overlooked this (despite having overloaded == for Model precisely for this reason 😄 ). This issue should be made explicit in the model API docs.

At first glance, this is likely not an issue in this case. As far as I can tell, the only place == for models is used is to check conditions for a "warm restart" when fit!ing a machine (https://alan-turing-institute.github.io/MLJ.jl/dev/machines/). If your model does not implement MMI.update, this is a moot point.

However, I think passing "empty objects" as way of specifying what is required is not ideal. What about doing something like mixtures=:diagonal_guassian. That way the user needn't refer to (and first find) the custom type DiagonalGuassian (currently buried as BetaML.Clustering.DiagonalGuassian). If possible, it's nice if users do not need to refer to model-specific types.

If the point is to maintain an interface point for "partially trained" mixtures, then the appropriate way to integrate with MLJ is to pass the mixtures (and posterior class probabilities) calculated by fit to cache and implement MMI.update, which continues training where it left off if the only change to the model is the iteration parameter (tested with MMI.is_same_except method). See https://alan-turing-institute.github.io/MLJ.jl/dev/adding_models_for_general_use/#Iterative-models-and-the-update!-method-1 . User access to trained mixtures is via fitted_params. (Another advantage of doing this is that MLJ will very soon have a model wrapper for controlling any iterative model of this kind, provided it is supervised - one reason for my suggesting having an implementation of GMM that is supervised.)

I should say that implementing update for the EM-based models is bells and whistles that could be added later. But good to keep in mind.

from betaml.jl.