Changes between Initial Version and Version 1 of Ticket #23000

05/15/17 03:13:08 (4 years ago)


  • Ticket #23000 – Description

    initial v1  
     1#18700 implements a new category `AdditiveGroups.Finite`. Without
     2further change, this triggered the following doctest failure:
     5sage: K = simplicial_complexes.Simplex(2)
     6sage: H = Hom(K,K)
     7sage: id = H.identity()
     8sage: id.induced_homology_morphism(GF(13)).base_ring()
     9Traceback (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]
     17KeyError: (258, 65)
     20This is yet another avatar of lack of robustness of categories over
     21base rings, which will be fixed by #20962 when module categories will
     22be singleton. To get the ball rolling for #18700 which is otherwise
     23ready, this ticket provides a quick workaround which should be robust
     24enough for now.
     27== Detailed analysis ==
     29Recall that
     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.
     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`, ...
     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.
     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()`
     52This risk will vanish by itself when module categories will be
     53singleton. In the mean time, adding "Modules" to the list of atom
     54categories guarantee that `AdditiveGroups().Finite()` gets a strictly
     55smaller key.