Initial work on combinatorial models of GATs #135
Draft
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This branch contains some experiments I've done with getting a canonical category of models for any GAT.
Relation to C-sets
This generalizes C-Sets, which correspond to models of theories with nullary type constructors and unary term constructors (ideally, C-Sets with all their performance characteristics should come automatically for such theories).
Rather than a FinSet for every Ob of a schema C, a GATset associates with each AlgSort a nested matrix, e.g. for
Hom2(f,g) ⊣ [(a,b)::Ob, (f,g)::Hom(a,b)]
there is a parameterized family of FinSets. We can automatically partition the four parameters ofHom2
into two dependent levels of parameters ([[a,b],[f,g]]
)|Hom2| is NOT equal to |Hom|², since
f
andg
are not completely independent: they must have the same dom and codom. E.g. if we have:|Ob| = 2 |Hom(1,1)| = 2 |Hom(2,1)| = 0 |Hom(1,2)| = 1 |Hom(2,2)| = 1
and give names to these elements, e.g.Ob=[ω,β] Hom(ω,ω) = [η,μ] Hom(β,ω) = [] Hom(ω,β) = [δ] Hom(β,β) = [ξ]
then we could potentially get a Hom2 matrix like:There is a rudimentary HTML printing for these nested matrices but they can also be rendered as a flattened table:
The
NestedMatrix{T}
data structure can be used for:T=Int
), as aboveid
/compose
(T=Int
)T=Vector{Int}
)Current features
add_part!
,rem_part!
homomorphisms(X,Y; monic, epic, iso, initial)
@instance ThCategory{CombinatorialModel, CombinatorialModelMorphism}
Wishlist
add/rem_part!
not reallocating)Enforcing equations
For these models to be particularly useful, we need to be able to enforce GAT axioms. This is done with C-Sets using the chase, which performs equality saturation via a sequence of pushouts. Based on some experiments, that algorithm won't work for GATsets (it doesn't terminate even in simple cases where it ought to). But this isn't a problem, because E-graphs have a semidecidable equality saturation algorithm. Corresponding to each model is an e-graph, with an e-node for each element of every dependent set. The nested matrix representation is less ideal for inference or modification, but a flexible shifting between e-graph and nested matrix could obtain the best of both worlds.
Interesting things
P::TYPE
,P'::TYPE
,D(p::P)::TYPE
,D'(p::P')::TYPE
,f(p::P)::P'
,f#(d)::D(p)⊣[p::P,d::D'(f(p))]
iso=[:I, :O]
constraint on homomorphism search, as this asserts the constraint for eachI(s::S,t::T)
(resp.O(s,t)
) dependent set (SeeNonStdlib.Theories.ThPetri
andtests/combinatorial/HomSearch.jl
)ThCategory
given any model ofThCategoryWithPushouts
, one way to verify the code is correct is to run the function through a series of randomly-generated models which implementThCategoryWithPushouts
(and check that the code doesn't crash, that the resulting models satisfy theThCategory
GAT axioms, etc.). The ability to do this kind of verification increases the value of writing generic code using GATlab.