module Order.Filter.Instances.Eventuality where
Eventuality filters🔗
When working with sequences it is common to find predicates that are true on almost every element of the sequence, but fail on a finite number of counterexamples. Mathematicians typically call such predicates “eventually always true” in the sequence.
The terminology for eventually always predicates is a bit inconsistent. Topologists and analysts refer to such predicates as “eventually true predicates”, whereas logicians typically adopt the “eventually always” naming convention. We prefer to use the more fine-grained terminology to avoid confusion.
As a concrete example, recall that a sequence converges to some if, for every there exists some such that for every further we have Ignoring constructivity concerns for the moment, we can re-phrase this definition in the language of eventually always true predicates by observing that a sequence converges if and only if there are a finite number of where In other words, a sequence converges if and only if the predicate is eventually always true in the sequence
Intuitively, for a fixed sequence in a type we ought to think about the subsets where is eventually always true in as somehow being “large” subsets of We can make this intuition precise by showing that this collection of subsets forms a filter on the power set of
However, we must first address the constructivity concerns that we previously ignored. There are two main problems that we must address:
The definition of eventual truth presented above required us to double negate to obtain and
Restricting ourselves to natural number-indexed sequences will cause problems with countable choice later down the line1.
We can resolve this first issue by replacing our definition of “ is eventually always true in ” with one that directly copies the structure of sequential convergence, EG:
To solve the second issue, we can generalize from sequences to nets.
A net in a type consists of a function from a upwards directed set
The natural numbers are upwards directed with respect to their canonical ordering, so every sequence gives rise to a net in
module _ {od ℓd ℓx} {D : Poset od ℓd} {X : Type ℓx} (D-directed : is-upwards-directed D) where private module D where open Poset D public open is-upwards-directed D-directed public open Filter open is-filter-base
With these pieces in place, we can now define the eventuality filter of a net.
The eventuality filter of a net is the filter defined as:
In more intuitive terms, is in the eventuality filter of if it eventually always lies within the image of
Eventuality : (⌞ D ⌟ → X) → Filter (Subsets X) Eventuality f .filter .hom A = elΩ (Σ[ i ∈ D ] (∀ j → i D.≤ j → f j ∈ A)) Eventuality f .filter .pres-≤ A⊆B = rec! λ i □A → inc (i , λ j i≤j → A⊆B (f j) (□A j i≤j))
The posets of subsets is a meet semilattice, so it suffices to show that is a meet semilattice homomorphism.
First, note that if and only if is inhabited, as the image of always lies within and is inhabited by definition.
Next, suppose that By definition, this means that there exists some and such that for all and resp.
Additionally, is directed, so there merely exists some upper bound Finally, for every as and
Eventuality f .has-is-filter = is-meet-slat-hom→is-filter Subsets-is-meet-slat record { top-≤ = λ _ → case D.inhabited of λ where i → inc (i , λ _ _ → tt) ; ∩-≤ = elim! λ A B i □A j □B → case D.upper-bound i j of λ where k i≤k j≤k → inc (k , λ l k≤l → □A l (D.≤-trans i≤k k≤l) , □B l (D.≤-trans j≤k k≤l)) }
Filter bases of the eventuality filter🔗
A tail of a net at some is set of all that lie in the image of some with 2.
Tail : (⌞ D ⌟ → X) → ⌞ D ⌟ → ℙ X Tail f i x = elΩ (Σ[ j ∈ D ] i D.≤ j × f j ≡ x)
The tails of form a filter base for the eventuality filter.
Tails-is-filter-base : {f : ⌞ D ⌟ → X} → is-filter-base (Eventuality f) (Tail f) Tails-is-filter-base .base∈F i = pure (i , λ j i≤j → pure (j , i≤j , refl)) Tails-is-filter-base .up-closed A = elim! λ i i≤j→f[j]∈A → pure (i , λ x → rec! (λ j i≤j fj=x → subst (_∈ A) fj=x (i≤j→f[j]∈A j i≤j)))
There are other topological reasons to generalize beyond sequences, but the topological content of constructive logic means that these problems with sequences have the same root cause. Similar situations arise when looking at and DCPOs, so this pattern of “sequences do not suffice” is common enough to make it worth avoiding from the get-go.↩︎
More abstractly, the tails of a net are the left Kan extensions of the hom functor along the monotone map ↩︎