Result · D-GUARDED-LLOYD
Exact gains guard Lloyd proposals
Proved herepublication: internal
Meaning
Accepting a Lloyd proposal only after an exact objective check preserves monotonicity.
Scientific context
Batch reassignment is available as a proposal generator, but every proposal it produces is accepted only on the exact objective, never taken on faith, because the unguarded step is not monotone (D-LLOYD-NONMONOTONE). This guard is part of the solver contract rather than an optional safeguard. Setting guard="exchange" hands the proposed labels to the exact exchange engine, so the reported state stays compilable afterward.
Statement
A batch Lloyd/Voronoi reassignment may be used as a proposal, but monotonicity is restored only by accepting proposals that improve the exact D objective.
practical acceleration
Closest prior work
Nearest prior work
Relationships
Rests on
- Adaptive Mahalanobis Lloyd need not increase DD-LLOYD-NONMONOTONE
- Exact finite D log-determinant gainD-LOGDET-GAIN
The full chain beneath it
Open next door
In the library
Carried by MahalanobisLloydConfig. Reference (opens in a new tab).
Local graph
Proof
D9. Adaptive Mahalanobis Lloyd is not monotone
The batch iteration “compute → nearest-centroid reassignment → recompute ” can decrease .
Reason:
so the fixed-metric tangent is an upper bound, not a minorizer.
Measured suite: decreasing steps occurred in 57/300 instances; one explicit example loses about 0.137 nat.
From D-optimality · chapter contents