RipserCohomologyContext

Ascending by filtration value; ties broken so a LARGER combinatorial index sorts as OLDER (smaller) -- the lexicographically-refined tie-break Definition 3.2/Proposition 3.9 rely on. Chain's leadingCell is the MINIMUM under whatever Ordering is supplied (Chain.from builds its PriorityQueue with ord.reverse), and persistent cohomology's pivot is the OLDEST cofacet in the reduced coboundary chain -- so this ascending ordering, not a reversed one, is what the coboundary-side Chain/RingModule machinery needs in scope. This is the opposite convention from CellularHomologyContext's stream.filtrationOrdering, which is deliberately reversed so ITS leadingCell means youngest -- see WORKLOG-cohomology.md for the full "transpose + reverse filtration order" derivation from the paper. Safe to declare at class scope (unlike the chainRM hazard documented on CellularHomologyContext): this ordering is self-contained, built directly from filtrationValue/si rather than by summoning some other ambient Ordering, so there is no stream-not-yet-available timing issue to worry about here.

Built directly on SimplexIndexing.CofacetCursor, not si.cofacetIterator + si(idx, ...) decode (.claude/WORKLOG-ripser-profiling.md): the vertex-less cofacetIterator would force every candidate to be fully decoded back into a Simplex[Int] and then linearly scanned just to recover the ONE vertex CofacetCursor already hands over directly as cur.vertex, on top of cofacetIteratorWithVertex's own (Int, Long) tuple allocation per candidate -- once the single largest remaining allocation source measured in this engine. tau is built by inserting cur.vertex directly into sigma's own vertex set (sigma.underlying + v, O(log d)), the same incremental-insertion sparseCofacets above already uses.

Coboundary of a whole chain, linearly extending coboundaryOf. Unlike Chain.scala's .boundary extension (intrinsic to a cell), a coboundary is extrinsic -- it depends on which higher-dimensional simplices exist in this (possibly truncated) complex -- so it lives here rather than as a general-purpose Chain extension. Used by tests to check that a representative essential cocycle genuinely has zero coboundary -- genuinely meaningful at every dimension up to and including maxDimension (not vacuously true at the top dimension anymore, since coboundaryOf now computes a real coboundary there too; see its own doc).

How many times the on-the-fly substitution above actually fired during the most recent persistentCohomology() call -- i.e. how many times some OTHER column's reduction reached an apparent pair's tau as an unresolved pivot and had to recompute that pair's coboundary on the fly. Exposed purely for testing: WORKLOG-lazy-enumeration.md's whole point is that this should be RARE (most apparent pairs are never looked up by anyone else's reduction) -- a test that only checks the final barcode is unchanged cannot distinguish "the fallback fired and computed correctly" from "the fallback never fired at all," so a discriminating test needs this counter, not just the bars.

Total number of simplices actually assembled across all dimensions during the most recent persistentCohomology() call -- exposed for testing. NOT Σ binomial(n, d+1): that formula assumes every combinatorially-possible subset exists, which is only true at maxFiltrationValue = +Infinity. For a genuinely thresholded complex most subsets never get generated at all (see sparseCofacets), so the finite*2 + essential == totalSimplices structural invariant RipserCohomologySpec checks needs THIS count, not the binomial formula, once a finite threshold is in play.

Optionally-memoized wrapper around rawFiltrationValue: MaximumDistanceFiltrationValue.apply recomputes an O(d^2) max over pairwise vertex distances from scratch on every call, with no caching of its own. Gated behind memoizeFiltrationValue (default false -- see the class doc above for why): the enumeration/assembly path (insertionDiameter, sparseCofacets, persistentCohomology's own per-dimension loop) never goes through this at all, carrying diameters incrementally instead, so this field's remaining callers are cohomologyOrdering (consulted on every SortedMap/PriorityQueue comparison inside Chain.reduceBy's reduction machinery) plus the handful of once-per-simplex lookups in coboundaryOf/zeroPivotCofacet/zeroPivotFacet/bar-endpoint reporting. See .claude/WORKLOG-lazy-enumeration.md for the measured cost of leaving this false.

Ascending by filtration value; ties broken so a LARGER combinatorial index sorts as OLDER (smaller) -- the lexicographically-refined tie-break Definition 3.2/Proposition 3.9 rely on. Chain's leadingCell is the MINIMUM under whatever Ordering is supplied (Chain.from builds its PriorityQueue with ord.reverse), and persistent cohomology's pivot is the OLDEST cofacet in the reduced coboundary chain -- so this ascending ordering, not a reversed one, is what the coboundary-side Chain/RingModule machinery needs in scope. This is the opposite convention from CellularHomologyContext's stream.filtrationOrdering, which is deliberately reversed so ITS leadingCell means youngest -- see WORKLOG-cohomology.md for the full "transpose + reverse filtration order" derivation from the paper. Safe to declare at class scope (unlike the chainRM hazard documented on CellularHomologyContext): this ordering is self-contained, built directly from filtrationValue/si rather than by summoning some other ambient Ordering, so there is no stream-not-yet-available timing issue to worry about here.