The product of two dg categories #
Objects are pairs, and the Hom-complex between two pairs is the degreewise product of the two Hom-complexes, with componentwise differential, identity and composition.
Unlike the opposite, no sign enters: the product is a limit construction and
every axiom holds componentwise. The work is entirely in getting Lean to see
the Hom-objects as products. AddCommGrpCat.of (_ × _)'s carrier is opaque to
instance search, so two techniques carry the file:
- Build at plain types.
prodCompis stated for arbitraryAddCommGroups and then applied to the carriers. Term elaboration unifies up to defeq, so this works where instance search does not. - Restate the projection lemmas where
simpwill match them.Prod.fst_adddoes not fire on(dgHom X Y).X p, because the operation carries the carrier's instance rather thanProd's. Therfllemmas below say the same thing at the type the goals actually have — and the type has to be exactly that one, not theprodComplexit unfolds to.
The differential of the degreewise product, named separately: a proof in a
later field of a structure instance cannot see an earlier field given inline,
so d has to exist before shape and d_comp_d' can mention it.
Equations
- One or more equations did not get rendered due to their size.
Instances For
The degreewise product of two cochain complexes of abelian groups.
Equations
- CategoryTheory.prodComplex K L = { X := fun (p : ℤ) => AddCommGrpCat.of (↑(K.X p) × ↑(L.X p)), d := CategoryTheory.prodD K L, shape := ⋯, d_comp_d' := ⋯ }
Instances For
Building the instance at plain types #
The obstacle the first attempt hit is that ((prodComplex K L).X p) is
AddCommGrpCat.of (_ × _), whose carrier instance search will not see
through. Term elaboration is a different matter: it unifies up to defeq, so a
helper stated at plain types with AddCommGroup instances applies to those
carriers without complaint.
So the composition is built once, generically, and then applied. Nothing below asks instance search to recognise a carrier as a product.
Componentwise biadditive composition on a pair of products.
Equations
- CategoryTheory.prodComp c₁ c₂ = AddMonoidHom.mk' (fun (a : A₁ × A₂) => ((c₁ a.1).comp (AddMonoidHom.fst B₁ B₂)).prod ((c₂ a.2).comp (AddMonoidHom.snd B₁ B₂))) ⋯
Instances For
The product of two dg categories.
Equations
- One or more equations did not get rendered due to their size.
Prod.fst_add and friends do not fire on these goals: the operations carry
the carrier's AddCommGroup instance, which is definitionally but not
syntactically Prod's, and simp matches syntactically. These rfl lemmas say
the same thing at the type the goals actually have.
The type matters twice over. Stating them at (prodComplex K L).X p is not
enough — the goals are about (dgHom X Y).X p for the product instance, which
is prodComplex … definitionally and not syntactically, so those versions miss
as well. They have to be stated exactly here.
The product dg category. Every axiom holds componentwise and no sign
enters, so each proof is Prod.ext followed by the corresponding axiom in each
factor.
Equations
- CategoryTheory.DGCategory.prod = { toDGCategoryStruct := CategoryTheory.DGCategory.prodStruct C D, dgComp_assoc := ⋯, dgId_comp := ⋯, dgComp_id := ⋯, dgId_cocycle := ⋯, dgComp_leibniz := ⋯ }