Class IncompleteFactorBaselineTest

java.lang.Object
ubic.gemma.core.util.test.BaseTest5
ubic.gemma.core.analysis.expression.diff.IncompleteFactorBaselineTest
@ContextConfiguration public class IncompleteFactorBaselineTest extends BaseTest5
A factor dropped for missing values must not be left behind in the baseline map.

dropIncompleteFactors removes a factor some sample carries no value for, and the design matrix is built from what survives. The baseline map is a second description of the same model, and makeDesignMatrix calls setBaseline for every entry it holds — so an entry for a dropped factor fails the whole analysis with No factor known by name fact.2, choices are: fact.1.

The subset path derives its baselines after both drops for exactly this reason, with a comment saying so. The whole-experiment path derived them before the drop.

Author:
gembro

  • Constructor Details

    • IncompleteFactorBaselineTest

      public IncompleteFactorBaselineTest()

  • Method Details

    • testAnIncompleteFactorDoesNotLeaveABaselineBehind

      @Test public void testAnIncompleteFactorDoesNotLeaveABaselineBehind()
      The rule: the dropped factor leaves the model AND the baseline map, and the analysis runs.

    • testACompleteFactorIsModelled

      @Test public void testACompleteFactorIsModelled()
      The positive control, off the same fixture: with every sample assigned a sex, nothing is dropped and both factors are modelled. Without it, an analysis that simply lost `sex` for an unrelated reason would pass the test above.

    • testASubsetsBaselineIsReassignedWithinTheSubset

      @Test public void testASubsetsBaselineIsReassignedWithinTheSubset()
      🛑 A subset's baseline must be REASSIGNED within that subset, not inherited from the whole experiment.

      doSubSetAnalysis took the experiment-wide baseline map and restricted its KEYS to the factors the subset can model. The VALUES stayed experiment-wide, so a factor that survives into a subset kept a baseline FactorValue that may not occur among that subset's samples, and DesignMatrix.setBaseline failed the subset with <fv> is not a level of the factor <fact>.

      The sibling path analyzeSubset has always done this correctly — getBaselineConditions( samplesInSubset, subsetFactors ), over the subset's own samples and after the factor drops, with a comment explaining why. This is the third "one path guarded, its twin bare" bug in a session, so the fix is to make the two agree rather than to special-case the symptom.

      frinkbro hit it on GSE33860 (eid 5905) subsetting by cell_type; it held 16 subset jobs. Paul's framing: "if you subset on organism part, that's a constant and isn't a factor within each subset. why is a baseline being sought?" — sought for a MODEL factor whose baseline arm is absent from some subsets — and "the baselines may have to be 'reassigned' within each subset."

      The fixture makes the baseline arm subset-specific on purpose: treatment has three levels and the FIRST sample carries untreated, which is what BaselineSelection.getBaselineConditions falls back to for the whole experiment. Subset B contains no untreated sample at all, so the experiment-wide baseline is not one of its levels.