InorderCofaceSimplexStream

Contract .iterator below relies on: the domain must be contiguous starting at 0 -- defined for 0, 1, ..., k for some k (or empty, or all of the non-negative integers), never with a gap. .iterator stops at the first dimension this is undefined for, so a non-contiguous domain (defined at d but not at d - 1) would silently truncate iteration instead of skipping the gap. Every implementation in this codebase already satisfies this (a simplicial complex can't have a d-simplex without its (d-1)-dimensional faces, so "no cells at d" implies "no cells at any dimension beyond d" too); a new implementation must preserve it.

Dimension-major: all of dimension d before any of dimension d + 1.

MUST NOT be implemented as Iterator.from(0).filter(iterateDimension.isDefinedAt)....fold(...) (a real, confirmed bug this replaced -- see WORKLOG-cohomology.md and Homology.scala's own historical workaround comment at PersistenceInChunksContext): Iterator.filter on an infinite source can never prove "no more matches ahead", so once past the last dimension iterateDimension is defined for, it spins forever searching for a d that will never come. .fold compounds this -- being a strict terminal operation, it can't yield anything until the (already-hanging) source is exhausted. Worse, for a guard shaped like d <= someBound (true for negative d too), Int silently wrapping from Int.MaxValue to Int.MinValue after ~2^31 iterations makes the guard spuriously true again, so instead of hanging forever this can eventually resume and feed a huge negative d straight to iterateDimension, surfacing as a BinomialCoefficient range exception rather than a hang. .takeWhile instead stops at the first d this is undefined for and never asks about any d beyond it, relying on exactly the contiguous-domain contract documented on iterateDimension above.

The number of elements in this collection, if it can be cheaply computed, -1 otherwise. Cheaply usually means: Not requiring a collection traversal.

Returns a scala.collection.Stepper for the elements of this collection.

The Stepper enables creating a Java stream to operate on the collection, see scala.jdk.StreamConverters. For collections holding primitive values, the Stepper can be used as an iterator which doesn't box the elements.

The implicit scala.collection.StepperShape parameter defines the resulting Stepper type according to the element type of this collection.

• For collections of Int, Short, Byte or Char, an scala.collection.IntStepper is returned
• For collections of Double or Float, a scala.collection.DoubleStepper is returned
• For collections of Long a scala.collection.LongStepper is returned
• For any other element type, an scala.collection.AnyStepper is returned

Note that this method is overridden in subclasses and the return type is refined to S with EfficientSplit, for example scala.collection.IndexedSeqOps.stepper. For Steppers marked with scala.collection.Stepper.EfficientSplit, the converters in scala.jdk.StreamConverters allow creating parallel streams, whereas bare Steppers can be converted only to sequential streams.

Filtration value, reversed (so smaller-under-this-ordering means YOUNGER, matching SimplexStream's own established convention -- see FilteredSimplexOrdering, and CellularHomologyContext's class doc, which relies on leadingCell meaning "youngest" wherever a stream's filtrationOrdering backs Chain's pivot machinery), then dimension, then COLEXICOGRAPHIC order on the vertex set (via simplexIndexing's own combinatorial-number-system index, not a fresh comparator -- this is exactly the "lexicographically refined" tie-break Ripser's own apparent-pairs machinery (Definition 3.2/Proposition 3.9, see RipserCohomologyContext) is defined in terms of, so using it here keeps this stream's ordering consistent with every other Ripser-flavored piece of this codebase, not just internally self-consistent -- deliberately not the plain lexicographic tie-break FilteredSimplexOrdering uses, which is the more generic, non-Ripser-specific default.

Fixes a real, previously-confirmed bug (see WORKLOG-cohomology.md for the full repro): the prior Ordering.by(filtrationValue) had NO tie-break at all, so two DIFFERENT simplices tied at the same filtration value compared as equal -- not a total order. This happens by construction (not rarely) on any Vietoris-Rips complex with a triangle, since a triangle's filtration value always equals that of its own longest edge. CellularHomologyContext bakes a stream's filtrationOrdering into Chain.reduceBy's SortedMap, so two cells that compare equal collide as a single map key and the reduction silently garbles pairings for that complex.

iterateDimension sorts each dimension's bucket by filtrationOrdering.reverse (oldest-first, the direction Algorithm 1 needs to process columns in) -- this is deliberately .reverse on this SAME Ordering object, not an independently-built "oldest first" comparator. A previous attempt used a separately-built ordering (via the structurally similar FilteredSimplexOrdering) for iteration while this ordering backed pivot selection; the two disagreed on tie-break direction, so a coface could sort before its own tied facet, corrupting Chain.reduceBy's pivot table exactly like the original no-tie-break bug did (see WORKLOG-cohomology.md). The general lesson: a stream's iteration order and its filtrationOrdering (pivot order) must be THE SAME total order (one the consistent reverse of the other) -- Algorithm 1 requires columns and rows to be indexed by one shared filtration order, not merely "each independently a valid total order." .reverse on this object, rather than a second hand-written comparator, is what guarantees that.