Changes between Version 6 and Version 7 of Ticket #23000


Ignore:
Timestamp:
05/15/17 22:26:44 (4 years ago)
Author:
nthiery
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • 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:
     2{{{
     3    sage: Modules(GF(3)).FiniteDimensional().is_subcategory(Sets().Finite())
     4    True
     5}}}
     6
     7However this piece of knowledge was ignored if a
     8base ring category instead of a base ring was passed to `Modules`:
     9{{{
     10    sage: Modules(Field().Finite()).FiniteDimensional().is_subcategory(Sets().Finite())
     11    True
     12}}}
     13
     14This ticket fixes this.
     15
     16== Comments ==
     17
     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
     21anymore.
     22
     23This issue was discovered while tracking a bug in #18700 which
     24implemented a new category `AdditiveGroups.Finite`, which triggered
     25the following doctest failure:
    326
    427{{{
     
    1841}}}
    1942
    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.
    25 
    26 
    2743== Detailed analysis ==
    2844
    29 Recall that
     45Recall that:
    3046
    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.
    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`, ...
     51  according to the order in which they are created (and some further
     52  data)
    4153
    4254- To avoid creating many copies of the same hierarchy of classes,
     
    4456  and therefore the same comparison key.
    4557
    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`.
    5163
    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.