id,summary,reporter,owner,description,type,status,priority,milestone,component,resolution,keywords,cc,merged,author,reviewer,upstream,work_issues,branch,commit,dependencies,stopgaps
23000,Fix inconsistency in `Modules.FiniteDimensional.extra_super_categories`,nthiery,,"Finite dimensional modules over a finite field are known to Sage to be finite:
{{{
sage: Modules(GF(3)).FiniteDimensional().is_subcategory(Sets().Finite())
True
}}}
However this piece of knowledge was ignored if a
base ring category instead of a base ring was passed to `Modules`:
{{{
sage: Modules(Field().Finite()).FiniteDimensional().is_subcategory(Sets().Finite())
True
}}}
This ticket fixes this.
== Comments ==
This is yet another avatar of the current lack of robustness of
categories over base rings. With #20962 which will make module
categories singletons, this kind of inconsistency won't be possible
anymore.
This issue was discovered while tracking a bug in #18700 which
implemented a new category `AdditiveGroups.Finite`, which triggered
the following doctest failure:
{{{
sage: K = simplicial_complexes.Simplex(2)
sage: H = Hom(K,K)
sage: id = H.identity()
sage: id.induced_homology_morphism(GF(13)).base_ring()
Traceback (most recent call last)
.../opt/sage-git2/src/sage/misc/c3_controlled.pyx in sage.misc.c3_controlled.C3_sorted_merge (/opt/sage-git2/src/build/cythonized/sage/misc/c3_controlled.c:5151)()
936 heads[j] = X
937 tailset = tailsets[j]
--> 938 tailset.remove(key(X))
939 else:
940 del heads[j]
KeyError: (258, 65)
}}}
== Detailed analysis ==
Recall that:
- categories are endowed with a total order which is used to ensure
that the Method Resolution Orders chosen by Python are always
consistent. This total order shall refine the subcategory relation.
This is achieved by assigning a comparison key to each category
according to the order in which they are created (and some further
data)
- To avoid creating many copies of the same hierarchy of classes,
parametrized categories may share their parent/element/... classes,
and therefore the same comparison key.
In the case at hand,
`C1=Modules(Fields().Finite().FiniteDimensional()` was created first.
Since it was not a subcategory of `A=AdditiveGroups().Finite()`, there
was no constraint on their relative comparison keys; it then turned
out that `C` was assigned a comparison key smaller than that of `A`.
Later on, when `C2=Modules(GF(3)).FiniteDimensional()` got created, it
got the same comparison key as `C1` while simultaneously deriving from
`A`, breaking the assumption.
",defect,closed,major,sage-8.0,categories,fixed,,tscrim,,Nicolas M. Thiéry,Travis Scrimshaw,N/A,,fc766203eaecbbf86767571c68dc569a02b2582c,fc766203eaecbbf86767571c68dc569a02b2582c,,