Summary
CLOISTER.m decides whether a hypercube corner combination "contradicts" a significant
feature-pair correlation using sign(Xedge(i,j)) ~= sign(Xedge(i,k)) /
sign(Xedge(i,j)) == sign(Xedge(i,k)) (confirmed at core/CLOISTER.m:91,93). This is only
meaningful if the feature values genuinely span both positive and negative territory — i.e. it
implicitly assumes mean-centred data.
Confirmed the call site (InstanceSpace.m:647): CLOISTER receives obj.model.data.X, which
is the post-PRELIM, Box-Cox+Z-scored feature matrix under default settings — so the sign check
is meaningful by default. But opts.prelim.norm=false is a legitimate, documented option
(disables normalisation). If a feature happens to be naturally all-positive in its raw scale
(counts, sizes — common in this domain) and normalisation is off, sign(Xedge(i,j)) becomes
degenerate for that feature — always the same sign — silently making the correlation-trend
filter meaningless for it, with no warning that this precondition was violated.
Proposed change
Add an explicit check in CLOISTER.m (or at its call site): if opts.prelim.norm was false for
this build, warn that the correlation-contradiction filter's sign-based logic assumes
mean-centred data and may not behave as intended.
Motivation
A silent-degradation risk under a real, supported configuration — cheap to guard against with a
warning, expensive to debug if someone hits it without knowing why their CLOISTER boundary looks
off.
Acceptance criteria
Part of the v0.9.1 milestone. Source: full-file audit pass over every core algorithm file plus previously-grepped-only utility files. Independent of batches 1, 2, 3, 5. Lower-stakes cleanup/edge-case item — any order relative to #43.
Summary
CLOISTER.mdecides whether a hypercube corner combination "contradicts" a significantfeature-pair correlation using
sign(Xedge(i,j)) ~= sign(Xedge(i,k))/sign(Xedge(i,j)) == sign(Xedge(i,k))(confirmed atcore/CLOISTER.m:91,93). This is onlymeaningful if the feature values genuinely span both positive and negative territory — i.e. it
implicitly assumes mean-centred data.
Confirmed the call site (
InstanceSpace.m:647):CLOISTERreceivesobj.model.data.X, whichis the post-PRELIM, Box-Cox+Z-scored feature matrix under default settings — so the sign check
is meaningful by default. But
opts.prelim.norm=falseis a legitimate, documented option(disables normalisation). If a feature happens to be naturally all-positive in its raw scale
(counts, sizes — common in this domain) and normalisation is off,
sign(Xedge(i,j))becomesdegenerate for that feature — always the same sign — silently making the correlation-trend
filter meaningless for it, with no warning that this precondition was violated.
Proposed change
Add an explicit check in
CLOISTER.m(or at its call site): ifopts.prelim.normwas false forthis build, warn that the correlation-contradiction filter's sign-based logic assumes
mean-centred data and may not behave as intended.
Motivation
A silent-degradation risk under a real, supported configuration — cheap to guard against with a
warning, expensive to debug if someone hits it without knowing why their CLOISTER boundary looks
off.
Acceptance criteria
reliably detected — e.g. checking
opts.prelim.norm/opts.norm.flagrather thaninspecting
X's actual sign distribution, which could false-positive on legitimatelymean-centred-but-still-all-one-sign-by-chance data)
Part of the
v0.9.1milestone. Source: full-file audit pass over every core algorithm file plus previously-grepped-only utility files. Independent of batches 1, 2, 3, 5. Lower-stakes cleanup/edge-case item — any order relative to #43.