FluidKMeans `setMeans` doesn't set `numClusters`

[tedmoore]

I would expect using setMeans with a dataset of n clusters would automatically set the KMeans object to look for n means, but it seems it does not. Instead I get ERROR: FluidKMeans - Wrong number of initial points. Is this intended behaviour?

s.boot;

// make and plot a dataset with 5 globs
(
fork{
	var counter = 0;
	var dict = Dictionary.newFrom(["cols",2,"data",Dictionary.new]);
	var xybuf = Buffer.alloc(s,2);

	1000.do{
		arg i;
		var x = [0.3,0.7,0.5,0.7,0.3][i % 5];
		var y = [0.3,0.7,0.5,0.3,0.7][i % 5];
		x = gauss(x,0.03).clip(0,1);
		y = gauss(y,0.03).clip(0,1);
		dict["data"][i] = [x,y];
	};

	~mean_seeds = FluidDataSet(s);

	~fp = FluidPlotter(bounds:Rect(0,0,800,800),dict:dict,mouseMoveAction:{
		arg view, x, y;
		xybuf.setn(0,[x,y]);
		~mean_seeds.addPoint(counter,xybuf,{
			counter = counter + 1;
			~mean_seeds.print;
		});
	});
}
)

(
~ds = FluidDataSet(s).load(~fp.dict);
~kmeans = FluidKMeans(s).setMeans(~mean_seeds);
~labels = FluidLabelSet(s);
~kmeans.fitPredict(~ds,~labels,{
	~labels.dump({
		arg labels;
		~fp.categories_(labels);
	});
});
)

[weefuzzy]

Insofar as that is what the code says, yes it's intentional, but I can see how it's not very convenient. Presumably one reason for the restriction is that k is unfortunately a parameter rather than just an argument to fit, and it's currently non-trivial for these to be set from clients.

Looking at the algorithm code, it does look like that restriction is assumed (if not documented), because the incoming means will simply be assigned to the existing array without checking that the sizes match. This would cause an assert crash in debug builds or undefined behaviour in release builds if the size didn't match.

I'm not 100% sure why it doesn't work like read / load though, i.e. junk the model and redo the assignments with whatever the new means happen to be, except that this would be much more expensive.

[tremblap]

r.e. last question: I think the idea was to allow increment poking/setting of the means

[weefuzzy]

Right, yes. The assignments aren't actually part of the important state of the model once its been fitted, which I lost sight of there (and which suggests a refactoring of the algorithm). Calling predict with some data will then give you some new assignments.

So, in principle, setMeans could just completely replace the existing model object, modulo some safety checking in the algo code to avoid UB.

[tedmoore]

So, in principle, setMeans could just completely replace the existing model object, modulo some safety checking in the algo code to avoid UB.

setMeans sounds to me like resetMeans since the means are the result of the fit setting new ones is going to overwrite any fitting that has happened, so yeah I think just replacing the existing model object makes sense.