Changes between Version 6 and Version 7 of Ticket #23000

05/15/17 22:26:44 (4 years ago)


  • Ticket #23000

    • Property Summary changed from Add trivial `AdditiveGroups.Finite` category, and workaround MRO issue to Fix inconsistency in `Modules.FiniteDimensional.extra_super_categories`
  • Ticket #23000 – Description

    v6 v7  
    1 #18700 implements a new category `AdditiveGroups.Finite`. Without
    2 further change, this triggered the following doctest failure:
     1Finite dimensional modules over a finite field are known to Sage to be finite:
     3    sage: Modules(GF(3)).FiniteDimensional().is_subcategory(Sets().Finite())
     4    True
     7However this piece of knowledge was ignored if a
     8base ring category instead of a base ring was passed to `Modules`:
     10    sage: Modules(Field().Finite()).FiniteDimensional().is_subcategory(Sets().Finite())
     11    True
     14This ticket fixes this.
     16== Comments ==
     18This is yet another avatar of the current lack of robustness of
     19categories over base rings. With #20962 which will make module
     20categories singletons, this kind of inconsistency won't be possible
     23This issue was discovered while tracking a bug in #18700 which
     24implemented a new category `AdditiveGroups.Finite`, which triggered
     25the following doctest failure:
    20 This is yet another avatar of lack of robustness of categories over
    21 base rings, which will be fixed by #22962 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.
    2743== Detailed analysis ==
    29 Recall that
     45Recall that:
    3147- categories are endowed with a total order which is used to ensure
    3349  consistent. This total order shall refine the subcategory relation.
    3450  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`, ...
     51  according to the order in which they are created (and some further
     52  data)
    4254- To avoid creating many copies of the same hierarchy of classes,
    4456  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()`
     58In the case at hand,
     59`C1=Modules(Fields().Finite().FiniteDimensional()` was created first.
     60Since it was not a subcategory of `A=AdditiveGroups().Finite()`, there
     61was no constraint on their relative comparison keys; it then turned
     62out that `C` was assigned a comparison key smaller than that of `A`.
    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.
     64Later on, when `C2=Modules(GF(3)).FiniteDimensional()` got created, it
     65got the same comparison key as `C1` while simultaneously deriving from
     66`A`, breaking the assumption.