The twist triangle of an object #
The evaluation map of an EvaluationData E is a closed degree-zero dg natural
transformation RHom(E,-) ⊗ E ⟶ id, and a choice of objectwise cones for it is
TwistConeData, whose cone functor is the twist T_E. Feeding that choice to
ConeData.triangleFunctor gives
H⁰ C ⥤ Triangle (H⁰ C), X ↦ (RHom(E,X) ⊗ E ⟶ X ⟶ T_E X ⟶ (RHom(E,X) ⊗ E)⟦1⟧),
every value distinguished. This is the Seidel--Thomas twist triangle of an
object, read as a triangle of functors on H⁰ rather than object by object.
How this differs from the adjunction twist triangle #
DGAdjunction.CounitConeData.twistTriangleFunctor is the same construction for
the counit of a dg adjunction. Anno--Logvinenko's twist is that one; the
Seidel--Thomas twist of an object is this one. They agree when RHom(E,-) and
- ⊗ E are the adjoint pair of a spherical functor out of Perf(k), which the
repository cannot state: it has no Perf(k) as a dg category. So the two twist
triangles coexist and neither is derived from the other.
What is claimed, and what is not #
That the triangle is functorial, that every value is distinguished, and that it
does not depend on either the chosen evaluation data or the chosen cones
(twistTriangleIsoOfEvaluation). The comparison is a natural isomorphism of
full triangle functors, with coherent identity and composition laws. The
original twistTriangleIso remains the definitional wrapper for changing only
the cone choices. All three facts come from the generic strict-square
cone-triangle layer; the only input beyond it is that evaluation is closed.
H⁰(T_E) is triangulated automatically: every dg functor preserves both
shift witnesses and the strong split cone witnesses.
Nothing here says T_E is an autoequivalence, calls E spherical, or connects
it to SerreFunctor.IsSphericalObject. The generic HasCopowers capability
does produce HasEvaluationData and a noncomputably selected
chosenEvaluationData; what remains open is a concrete dg category carrying
that capability. Being exact is not being an autoequivalence. The comparison
maps between different choices are invertible, but the object twist functor
itself has no autoequivalence statement -- the adjunction twist gets one from
TwistCotwistEquivalenceConditions, which has no object-level counterpart.
Where the first two maps come from #
twistTriangleFunctor_obj_mor₁ identifies the first map with evaluation read on
H⁰, and ..._mor₂ identifies the second with the canonical inclusion
id ⟶ T_E. As with the adjunction twist, the triangle's maps are the data
already present, not new choices.
The twist triangle of an object, as a functor on H⁰.
X ↦ (RHom(E,X) ⊗ E ⟶ X ⟶ T_E X ⟶ (RHom(E,X) ⊗ E)⟦1⟧).
Equations
Instances For
Every value of the object twist triangle functor is distinguished.
The first map is evaluation, read on H⁰.
The second map is the canonical inclusion id ⟶ T_E.
H⁰(T_E) commutes with the shift.
This is the object-twist name for the canonical dg-functor package.
Equations
Instances For
The object twist is exact on H⁰.
Both dg-level capabilities are available for every dg functor, so H⁰ of the
twist commutes with the shift and carries distinguished triangles to
distinguished triangles.
This is exactness, not invertibility: nothing here says T_E is an
equivalence.
The object twist triangle does not depend on the chosen cones.
Equations
Instances For
The object twist triangle does not depend on the evaluation or cone choices.
The separately named definition preserves the original twistTriangleIso
contract, which remains the direct generic cone-choice comparison.
Equations
- One or more equations did not get rendered due to their size.