Motivation
ExtAlgebra<CC> currently conflates two different objects:
- the ring
Ext(k, k) — genuinely an algebra;
- the module
Ext(M, k) — a module over that ring, not an algebra (the struct's own docs note "when M == k this is the algebra Ext(k, k) itself").
One struct plays both roles, carrying resolution (of M), unit (of k), an is_unit flag, and a products cache keyed on generators of the resolution/M side (resolution → unit maps).
The cache therefore has no home for a purely ring-side operation: multiplication by a class b ∈ Ext(k, k). This surfaced while fixing #116 (see #258): massey_b_hom has to build the multiply-by-b chain map (unit → unit) fresh via ResolutionHomomorphism::from_class every call, because when M ≠ k that map is not what products stores. It only coincides with a cached map in the M == k case, and even then only for single generators (the cache is per-generator; class products are assembled at the hom_k level, not as a single chain map).
Proposed structure
ExtAlgebra — owns the resolution of k and the ring-product cache (products among Ext(k, k) generators, unit → unit, built and extended once). This becomes the single source of the multiply-by-b maps that massey_b_hom needs.ExtModule — owns the resolution of M, a shared Arc<ExtAlgebra> (a shared handle, so all modules over the same k share one ring cache — not a per-module copy, or the caching wouldn't actually be shared), and the module-action cache (M's Ext-generators acted on by ring elements, resolution → unit).M == k collapses to "a module over itself," retiring the is_unit special-casing and without_unit.
Benefits
- The ring multiplication (mult-by-
b) is cached once in ExtAlgebra and reused across every module and every product/Massey computation.
- Correct semantics and naming: algebra vs. module.
- The Massey code separates cleanly:
massey_b_hom → cached map from the ExtAlgebra; massey_kernel → module-action cache; massey_bracket_of composes the two. The b (ring-side) vs c (module-side) asymmetry in massey_bracket_of stops being a smell.
Scope / notes
This touches all of ext/src/ext_algebra/ (mod.rs, massey.rs, secondary.rs + SecondaryExtAlgebra), every example/consumer that constructs an ExtAlgebra, and possibly the web GUI. It is intentionally out of scope for the #116 fix (#258), which stays a focused bug fix. Related: #184 (cohomology abstraction layer).
Filed from discussion on #258.
Motivation
ExtAlgebra<CC>currently conflates two different objects:Ext(k, k)— genuinely an algebra;Ext(M, k)— a module over that ring, not an algebra (the struct's own docs note "whenM == kthis is the algebraExt(k, k)itself").One struct plays both roles, carrying
resolution(ofM),unit(ofk), anis_unitflag, and aproductscache keyed on generators of the resolution/Mside (resolution → unitmaps).The cache therefore has no home for a purely ring-side operation: multiplication by a class
b ∈ Ext(k, k). This surfaced while fixing #116 (see #258):massey_b_homhas to build the multiply-by-bchain map (unit → unit) fresh viaResolutionHomomorphism::from_classevery call, because whenM ≠ kthat map is not whatproductsstores. It only coincides with a cached map in theM == kcase, and even then only for single generators (the cache is per-generator; class products are assembled at thehom_klevel, not as a single chain map).Proposed structure
ExtAlgebra— owns the resolution ofkand the ring-product cache (products amongExt(k, k)generators,unit → unit, built and extended once). This becomes the single source of the multiply-by-bmaps thatmassey_b_homneeds.ExtModule— owns the resolution ofM, a sharedArc<ExtAlgebra>(a shared handle, so all modules over the samekshare one ring cache — not a per-module copy, or the caching wouldn't actually be shared), and the module-action cache (M's Ext-generators acted on by ring elements,resolution → unit).M == kcollapses to "a module over itself," retiring theis_unitspecial-casing andwithout_unit.Benefits
b) is cached once inExtAlgebraand reused across every module and every product/Massey computation.massey_b_hom→ cached map from theExtAlgebra;massey_kernel→ module-action cache;massey_bracket_ofcomposes the two. Theb(ring-side) vsc(module-side) asymmetry inmassey_bracket_ofstops being a smell.Scope / notes
This touches all of
ext/src/ext_algebra/(mod.rs,massey.rs,secondary.rs+SecondaryExtAlgebra), every example/consumer that constructs anExtAlgebra, and possibly the web GUI. It is intentionally out of scope for the #116 fix (#258), which stays a focused bug fix. Related: #184 (cohomology abstraction layer).Filed from discussion on #258.