#10963: More functorial constructions
-------------------------------------------------------------------------+--
       Reporter:  nthiery                                                |      
   Owner:  stumpc5                                                              
                        
           Type:  enhancement                                            |      
  Status:  needs_work                                                           
                        
       Priority:  major                                                  |     
Milestone:                                                                      
                         
      Component:  categories                                             |    
Resolution:                                                                     
                          
       Keywords:                                                         |   
Work issues:  Reduce startup time by 5%. Avoid "recursion depth exceeded 
(ignored)". Trivial doctest fixes.
Report Upstream:  N/A                                                    |     
Reviewers:  Simon King                                                          
                         
        Authors:  Nicolas M. ThiƩry                                      |     
Merged in:                                                                      
                         
   Dependencies:  #11224, #8327, #10193, #12895, #14516, #14722, #13589  |      
Stopgaps:                                                                       
                        
-------------------------------------------------------------------------+--

Comment (by SimonKing):

 I guess I should re-think the above in a more concrete scenario. Let `D =
 DivisionRings()`. What do we do with `D.Finite()`?

 Would we agree on `D = Rings().WithMultiplicativeInverses()`? I guess we
 would obtain `Fields()=D.Commutative()`. So, as in the situation above, we
 have the rule that if `WithMultiplicativeInverses()` is applied to
 `Rings()`, then the additional axiom `Finite()` implies the axiom
 `Commutative()`.

 Hence, `D.Finite()` yields `Fields().Finite()=FiniteFields()`. To be
 discussed: Should this be created dynamically, or should there be a hard-
 coded separate class definition?

 So, what would `FiniteFields().super_categories()` return by the algorithm
 I presented above?
 - Omit `Commutative`: We still have the axioms
 `WithMultiplicativeInverses` and `Finite`, hence, we recover
 `FiniteFields()`, which is thus a duplicate and not part of
 `FiniteFields().super_categories()`.
 - Omit `Finite`: The remaining axioms are those of commutative division
 rings, which yields `Fields()`.
 - Omit `WithMultiplicativeInverses`: Yields finite commutative rings.

 So, `FiniteFields().super_categories()`returns `[Fields(),
 Rings().Commutative().Finite()]`. Do you think this answer makes sense?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/10963#comment:51>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to