| 1 | #18700 implements a new category `AdditiveGroups.Finite`. Without |
| 2 | further change, this triggered the following doctest failure: |
| 3 | |
| 4 | {{{ |
| 5 | sage: K = simplicial_complexes.Simplex(2) |
| 6 | sage: H = Hom(K,K) |
| 7 | sage: id = H.identity() |
| 8 | sage: id.induced_homology_morphism(GF(13)).base_ring() |
| 9 | Traceback (most recent call last) |
| 10 | .../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)() |
| 11 | 936 heads[j] = X |
| 12 | 937 tailset = tailsets[j] |
| 13 | --> 938 tailset.remove(key(X)) |
| 14 | 939 else: |
| 15 | 940 del heads[j] |
| 16 | |
| 17 | KeyError: (258, 65) |
| 18 | }}} |
| 19 | |
| 20 | This is yet another avatar of lack of robustness of categories over |
| 21 | base rings, which will be fixed by #20962 when module categories will |
| 22 | be singleton. To get the ball rolling for #18700 which is otherwise |
| 23 | ready, this ticket provides a quick workaround which should be robust |
| 24 | enough for now. |
| 25 | |
| 26 | |
| 27 | == Detailed analysis == |
| 28 | |
| 29 | Recall that |
| 30 | |
| 31 | - categories are endowed with a total order which is used to ensure |
| 32 | that the Method Resolution Orders chosen by Python are always |
| 33 | consistent. This total order shall refine the subcategory relation. |
| 34 | This is achieved by assigning a comparison key to each category |
| 35 | according to the order in which they are created. |
| 36 | |
| 37 | - To make the total order more reproducible from one session to the |
| 38 | other, the first piece of the comparison key is given by a bit array |
| 39 | of flags which are set according to whether the category is a |
| 40 | subcategory of some "atom categories": `FacadeSets`, `FiniteSets`, ... |
| 41 | |
| 42 | - To avoid creating many copies of the same hierarchy of classes, |
| 43 | parametrized categories may share their parent/element/... classes, |
| 44 | and therefore the same comparison key. |
| 45 | |
| 46 | In the case at hand, depending on the order in which categories were |
| 47 | created, the assumption of refining the subcategory relation got |
| 48 | broken (I still need to analyze this precisely): |
| 49 | `Modules(GF(3)).FiniteDimensional()` got a key smaller than its |
| 50 | super category `AdditiveGroup().Finite()` |
| 51 | |
| 52 | This risk will vanish by itself when module categories will be |
| 53 | singleton. In the mean time, adding "Modules" to the list of atom |
| 54 | categories guarantee that `AdditiveGroups().Finite()` gets a strictly |
| 55 | smaller key. |