Changes between Version 6 and Version 7 of Ticket #23000
 Timestamp:
 05/15/17 22:26:44 (4 years ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #23000

Property
Summary
changed from
Add trivial `AdditiveGroups.Finite` category, and workaround MRO issue
toFix inconsistency in `Modules.FiniteDimensional.extra_super_categories`

Property
Summary
changed from

Ticket #23000 – Description
v6 v7 1 #18700 implements a new category `AdditiveGroups.Finite`. Without 2 further change, this triggered the following doctest failure: 1 Finite 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 7 However this piece of knowledge was ignored if a 8 base 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 14 This ticket fixes this. 15 16 == Comments == 17 18 This is yet another avatar of the current lack of robustness of 19 categories over base rings. With #20962 which will make module 20 categories singletons, this kind of inconsistency won't be possible 21 anymore. 22 23 This issue was discovered while tracking a bug in #18700 which 24 implemented a new category `AdditiveGroups.Finite`, which triggered 25 the following doctest failure: 3 26 4 27 {{{ … … 18 41 }}} 19 42 20 This is yet another avatar of lack of robustness of categories over21 base rings, which will be fixed by #22962 when module categories will22 be singleton. To get the ball rolling for #18700 which is otherwise23 ready, this ticket provides a quick workaround which should be robust24 enough for now.25 26 27 43 == Detailed analysis == 28 44 29 Recall that 45 Recall that: 30 46 31 47  categories are endowed with a total order which is used to ensure … … 33 49 consistent. This total order shall refine the subcategory relation. 34 50 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) 41 53 42 54  To avoid creating many copies of the same hierarchy of classes, … … 44 56 and therefore the same comparison key. 45 57 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()` 58 In the case at hand, 59 `C1=Modules(Fields().Finite().FiniteDimensional()` was created first. 60 Since it was not a subcategory of `A=AdditiveGroups().Finite()`, there 61 was no constraint on their relative comparison keys; it then turned 62 out that `C` was assigned a comparison key smaller than that of `A`. 51 63 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. 64 Later on, when `C2=Modules(GF(3)).FiniteDimensional()` got created, it 65 got the same comparison key as `C1` while simultaneously deriving from 66 `A`, breaking the assumption.