partitionStability

How far the reported density moves when the cuts between the components are nudged.

Every component is estimated from its own group, so every reported component depends on where two cuts fell. This moves each interior cut a little way along the axis the data lives on, refits the components from the groups that result, and reports how far the density travelled. A fit whose cuts sit in real gaps does not move at all, because nothing changes group; a fit whose cuts were placed arbitrarily through a single blob moves with them.

The displacement is in data units and the refits are not refined. Both matter. Moving a cut by a fixed number of observations, or widening each component's estimation window, always reassigns data across the boundary, and disturbs a genuinely well-separated fit the most — the observations that cross are then the most alien available. That inverts the reading, which is why this does not use WindowedComponentFitter as the plan's Phase E first proposed. And re-refining a displaced partition would walk the cuts straight back to where they came from, measuring nothing.

On the modeler rather than on the results, and that is a deviation from the plan. The plan put this on MixtureModelingResults, which carries the data and the criterion but not the fitter, the generator or the selector. An extension there would have to refit with defaults, so for anyone who fitted with anything else the measured movement would be the sum of two changes — the displaced cuts, and a different estimator — reported as if it were the first. Here the modeler's own fitter and cache do the refitting, so the cuts are the only thing that differs and the number means what it says.

Nothing fitted here is returned. Each alternative is measured against the baseline and dropped; the answer is a distance, not another density to choose from.

Parameters

Throws