IncrementalVietorisRipsSimplexStream

org.appliedtopology.tda4j.streams.IncrementalVietorisRipsSimplexStream
class IncrementalVietorisRipsSimplexStream(metricSpace: FiniteMetricSpace[Int], val maxDimension: Int, maxFiltrationValue: Option[Double] = ..., keepCriterion: PartialFunction[Simplex[Int], Boolean] = ..., useLargestNeighborBound: Boolean = ...) extends EnumeratingCofaceSimplexStream

A straightforward, non-optimized reference implementation of a Vietoris-Rips coface stream, following Antonio Rieser's New-VR algorithm ("A New Construction of the Vietoris-Rips Complex", arXiv:2301.07191v3) -- an explicit refinement of Zomorodian's own Incremental-VR algorithm (Algorithms 6/7 in that paper's Section 4; the algorithm EnumeratingCofaceSimplexStream and its siblings above are alternate, independently-optimized engines for the same construction). Kept intentionally close to the paper's own Algorithms 1-4, as a solid baseline the other, more experimental streams in this file can be cross-validated against, rather than as a speed-competitive engine in its own right.

The paper phrases the construction as a depth-first recursion over a simplex tree (New-Add-Cofaces, Algorithm 3), but its own prose description of the "inductive step" (Section 3, immediately above Algorithm 1) is equivalently a breadth-first, layer-by-layer construction: layer D(k+1) is built entirely from layer D(k) and each of that layer's own candidate/sibling lists. This class uses that framing so it can slot into iterateDimension's per-dimension contract like every other CofaceSimplexStream here. Since iterateDimension is a PartialFunction that may be called for any dimension in any order (unlike a genuinely incremental engine such as RipserCofaceSimplexStream, which depends on being driven dimension-by-dimension), the whole complex is built eagerly, once, into byDimension, and every call just serves a bucket from it -- simpler and safer than making the recursive construction itself resumable/order-independent.

maxFiltrationValue (default +Infinity) is the threshold defining the graph G whose clique complex the paper's algorithm builds: {i,j} ∈ E iff metricSpace.distance(i,j) v, {v,w} ∈ E}) -- see IncrementalVietorisRipsSpec for a pinned test that including it changes nothing about the output.

No deduplication is needed anywhere in this construction: every simplex is reached via exactly one recursive path, built by always appending vertices in increasing order from a candidate list that only ever contains vertices greater than every vertex already in tau (Theorem 2.5's minimal-pair bijection, in the paper's own terms). If a bug ever makes a simplex appear twice, that is a sign the recursion itself is wrong, not a reason to add a dedup step.

One deliberate departure from Algorithm 4 as written: the paper's own pseudocode does Σ ← V ∪ E unconditionally, before the main loop, so the full 1-skeleton is always present regardless of d. Here maxDimension instead behaves exactly like LimitedCofaceSimplexStream's maxDim -- the highest dimension iterateDimension will ever serve -- so maxDimension = 0 yields vertices only, with no edges, unlike the paper's own Σ. This matches every other bounded stream in this codebase and is what a caller building up dimension-by-dimension would expect.

Attributes

Experimental
true
Graph
Supertypes
trait CofaceSimplexStream[Int, Double]
trait StratifiedSimplexStream[Int, Double]
trait StratifiedCellStream[Simplex[Int], Double]
trait CellStream[Simplex[Int], Double]
trait IterableOnce[Simplex[Int]]
trait Filtration[Simplex[Int], Double]
trait Filterable[Double]
class Object
trait Matchable
class Any
Show all

Members list

Value members

Concrete methods

override def iterateDimension: PartialFunction[Int, Iterator[Simplex[Int]]]

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.

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.

Attributes

Definition Classes

Inherited methods

override def iterator: Iterator[Simplex[Int]]

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

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 .claude/WORKLOG-cohomology.md): 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 -- and Int silently wrapping from Int.MaxValue to Int.MinValue after ~2^31 iterations can eventually feed a huge negative d straight to iterateDimension instead, 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.

Attributes

Definition Classes
StratifiedCellStream -> IterableOnce
Inherited from:
StratifiedCellStream
def knownSize: Int

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

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

Attributes

Inherited from:
IterableOnce
def stepper[S <: Stepper[_]](implicit shape: StepperShape[Simplex[Int], S]): S

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

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.

Type parameters

S

the type of the returned Stepper, determined by the implicit StepperShape

Attributes

Inherited from:
IterableOnce

Concrete fields

val maxDimension: Int

Inherited fields

var currentDimension: Int

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
var currentDimensionCache: Queue[Simplex[Int]]

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
lazy val edges: Iterable[Simplex[Int]]

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
override val filtrationOrdering: Ordering[Simplex[Int]]

Filtration value, reversed (so smaller-under-this-ordering means YOUNGER, matching SimplexStream's own established convention), then dimension, then COLEXICOGRAPHIC order on the vertex set (via simplexIndexing's own combinatorial-number-system index) -- 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.

Filtration value, reversed (so smaller-under-this-ordering means YOUNGER, matching SimplexStream's own established convention), then dimension, then COLEXICOGRAPHIC order on the vertex set (via simplexIndexing's own combinatorial-number-system index) -- 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.

Fixes a real, previously-confirmed bug (.claude/WORKLOG-cohomology.md): a bare Ordering.by(filtrationValue) has no tie-break at all, so two DIFFERENT simplices tied at the same filtration value compare as equal -- not a total order. This happens by construction 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 -- deliberately .reverse on this SAME Ordering object, not an independently-built "oldest first" comparator: two individually-valid orderings that disagree on tie-break direction let a coface sort before its own tied facet, corrupting Chain.reduceBy's pivot table the same way the no-tie-break bug did. A stream's iteration order and its filtrationOrdering (pivot order) must be THE SAME total order, one the consistent reverse of the other.

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
override val filtrationValue: PartialFunction[Simplex[Int], Double]

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
val largest: Double

Attributes

Inherited from:
DoubleFiltration
var lastDimensionCache: IndexedSeq[Simplex[Int]]

Attributes

Inherited from:
EnumeratingCofaceSimplexStream

Attributes

Inherited from:
EnumeratingCofaceSimplexStream
val smallest: Double

Attributes

Inherited from:
DoubleFiltration