Tensoring a dg object by a complex #
The evaluation functor RHom(E,-) ⊗ E needs an object K ⊗ X for a complex
K and an object X, and the repository has no tensor product to build it
with: at the pinned Mathlib revision HomologicalComplex.HasTensor does not
synthesize for the ℤ-indexed shape, which is the whole reason DGCategory
encodes composition as a family of biadditive maps rather than a chain map out
of a tensor product (ADR-0010, ADR-0011).
So the tensoring is stated the way IsShiftBy states the shift: by its
universal property, as data plus a bijectivity condition, with no construction
of the object. IsCopowerOf K X Z says Z is K ⊗ X, in the only sense
that matters — degree-p morphisms out of Z are degree-p cochains out of
K into the Hom-complex of X.
Why cochains are spelled out #
A degree-p cochain K ⟶ dgHom X W is an additive map K i ⟶ (dgHom X W) j
for every i + p = j. Mathlib's CochainComplex.HomComplex.Cochain packages
exactly that, but naming it here would drag in the Triplet encoding and the
δ API for no gain: the two conditions below are stated directly on the
families, in the same vocabulary as the rest of this directory.
What the bijectivity is for #
Everything. IsShiftBy gets its inverse, its uniqueness and its transport
from one bijectivity assumption, and the same three follow here:
IsCopowerOf.lift inverts the bijection, lift_unique says a morphism out of
a copower is determined by the cochain it induces, and compare makes any two
copowers of the same data canonically isomorphic in Z⁰.
HasCopower K X and HasCopowers C package mere existence in the same style
as Mathlib's HasLimit and HasLimitsOfShape: the classes store no selected
object, and the noncomputable copowerData API makes a choice only when a
consumer asks for one. HasEvaluationData E is the narrower existence
interface consumed by the object-twist construction; all copowers imply it.
The evaluation functor #
EvaluationData E is a choice of copower of E by dgHom E X for every X,
in the same shape as ConeData: objectwise data, assembled into a dg functor.
Its functor is RHom(E,-) ⊗ E and its evaluation is the transformation to
the identity, whose component at X is the morphism corresponding to the
identity cochain of dgHom E X. Any two choices are connected by
EvaluationData.compareIso, a canonical isomorphism in the closed
degree-zero dg-functor category, and that comparison commutes strictly with
evaluation.
Every one of the functor's four laws is lift_unique applied to the cochain
each side induces; only map_d needs anything beyond associativity, and there
it is the Leibniz rule twice, once in C and once in the Hom-complex.
What this does not give #
Concrete existence. Nothing here proves that a particular dg category has
copowers. Once a category supplies the HasCopowers capability, however,
HasEvaluationData and chosenEvaluationData produce the evaluation data
without adding compatibility fields or a second choice mechanism. Nothing
here relates this functor to a spherical object: that comparison needs
Perf(k) as a dg category, which the repository does not have.
The degree-p cochain that a degree-p morphism out of a copower induces:
apply the universal family, then compose.
Equations
- CategoryTheory.copowerCochain univ p g i j h = AddMonoidHom.mk' (fun (x : ↑(K.X i)) => ((CategoryTheory.DGCategoryStruct.dgComp i p j h) ((univ i) x)) g) ⋯
Instances For
Z is the tensoring of X by the complex K.
The data is a chain map K ⟶ dgHom X Z, and the condition is that composing
with it identifies degree-p morphisms out of Z with degree-p cochains out
of K, for every degree and every target. This is IsShiftBy's pattern: the
object is not built, only characterised.
The universal family, degree by degree.
- univ_d (i j : ℤ) (x : ↑(K.X i)) : (self.univ j) ((AddCommGrpCat.Hom.hom (K.d i j)) x) = (AddCommGrpCat.Hom.hom ((DGCategoryStruct.dgHom X Z).d i j)) ((self.univ i) x)
It is a chain map.
- bijective (W : C) (p : ℤ) : Function.Bijective fun (g : ↑((DGCategoryStruct.dgHom Z W).X p)) => copowerCochain self.univ p g
Composing with it is bijective onto cochains, in every degree and from every target.
Instances For
A morphism out of a copower is determined by the cochain it induces.
Every cochain out of K is induced by a morphism out of the copower.
Instances For
The comparison between two copowers of the same data: the lift of the other one's universal family.
The index is normalised with cases rather than subst: the cochain is indexed
by i + 0 = j, and j is the variable that has to go.
Equations
- One or more equations did not get rendered due to their size.
Instances For
The canonical comparison is closed, hence is a morphism in Z⁰ C.
Both universal families are chain maps. Applying the Leibniz rule to the source universal family followed by the comparison leaves the differential of the comparison as the only unmatched term, and the universal property detects that it vanishes.
Any two copowers of the same data are canonically isomorphic. The two
comparisons compose to the identity, so the object IsCopowerOf characterises
is unique up to a canonical degree-zero isomorphism.
Canonical copower comparisons compose. Together with
compare_comp_compare and compare_self, this makes the copower choices for
fixed K and X a contractible groupoid inside Z⁰ C.
Comparing a copower with itself is the identity.
A copower object together with its universal-property witness.
- obj : C
The chosen copower object.
- isCopower : IsCopowerOf K X self.obj
The universal property witnessed by the chosen object.
Instances For
Mere existence of a copower of X by K.
Like Mathlib's HasLimit, this proposition carries no preferred choice in its
public contract. The choice is made only by copowerData.
- exists_copower : Nonempty (CopowerData K X)
Instances
A witnessed copower supplies the corresponding existence instance.
A noncomputably selected copower and its witness.
Equations
Instances For
The copower object selected from HasCopower K X.
Equations
Instances For
The universal-property witness for the selected copowerObj K X.
Equations
Instances For
Existence of all copowers by integer cochain complexes.
Instances
All copowers give each individual copower. The low priority leaves room for a category to expose a more specific local construction.
A choice of RHom(E,X) ⊗ E for every X.
The same shape as HomogeneousNatTrans.ConeData: objectwise data that the
next declarations assemble into a dg functor.
- obj : C → C
The chosen object
RHom(E,X) ⊗ E. - isCopower (X : C) : IsCopowerOf (DGCategoryStruct.dgHom E X) E (self.obj X)
It is the copower of
Eby the Hom-complex out ofE.
Instances For
Mere existence of the copowers needed for evaluation at E.
- exists_evaluationData : Nonempty (EvaluationData E)
Instances
Evaluation data noncomputably selected from HasEvaluationData E.
Equations
Instances For
All copowers supply the family of copowers needed for evaluation at E.
Equations
- One or more equations did not get rendered due to their size.
Instances For
A category with all copowers has evaluation data at every object.
The action on a homogeneous morphism: postcompose inside the Hom-complex, then lift.
Equations
- One or more equations did not get rendered due to their size.
Instances For
The evaluation functor RHom(E,-) ⊗ E.
Equations
Instances For
Not @[simp]: functor_obj rewrites inside this statement's own type, so
the left-hand side is not in simp normal form and simpNF rejects it. The
same reason keeps DGFunctor.shiftedFunctor_map off the simp set.
The evaluation morphism at X: the morphism RHom(E,X) ⊗ E ⟶ X induced
by the identity cochain of dgHom E X. That is exactly what "evaluate"
means.
The index is normalised with cases rather than subst, for the reason given
at IsCopowerOf.compare.
Equations
- One or more equations did not get rendered due to their size.
Instances For
The evaluation transformation RHom(E,-) ⊗ E ⟶ id.
It is homogeneous of degree zero, so its Koszul sign is trivial and naturality
is the plain square: both sides are the cochain k ↦ k · f.
Equations
- V.evaluation = ⟨V.evalHom, ⋯⟩
Instances For
The evaluation transformation is closed.
Componentwise this is the Leibniz rule against the identity cochain: the
universal family is a chain map, so differentiating univ i k · eval produces
the same term twice, once from each factor, and the factor that carries
d eval is what is left.
Closedness is what lets evaluation have a cone, which is the twist.
The canonical closed natural comparison between two choices of evaluation data. Objectwise it is the canonical comparison between their copowers.
Instances For
The canonical comparison is closed because its components are closed.
Canonical comparisons compose strictly.
The comparison from an evaluation choice to itself is the identity.
The canonical comparison between two evaluation choices as an isomorphism in the closed degree-zero dg-functor category.
Equations
Instances For
The canonical evaluation-data comparison from a choice to itself is the identity isomorphism.
Canonical evaluation-data comparison isomorphisms are transitive.
The canonical comparison commutes strictly with evaluation.