#15229: Improved use of category framework for IntegerModRing
-------------------------------------+-------------------------------------
       Reporter:  SimonKing          |        Owner:
           Type:  defect             |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.1
      Component:  categories         |   Resolution:
       Keywords:  sd53 category      |    Merged in:
  integermodring                     |    Reviewers:
        Authors:  Simon King         |  Work issues:
Report Upstream:  N/A                |       Commit:
         Branch:                     |  2a08a447be22e4307372524c4b94ca0577d927c9
  u/SimonKing/ticket/15229           |     Stopgaps:
   Dependencies:                     |
-------------------------------------+-------------------------------------

Comment (by SimonKing):

 Replying to [comment:52 nthiery]:
 > I for myself would tend to just support the {{{category=Fields()}}}
 syntax.
 >
 > Imagine a case where the parent could have five different axioms
 depening on the input; then you'd have to support five arguments when only
 one does the trick uniformly. That's not a completely insane thought: e.g.
 for non-commutative groebner basis your could have as axioms: finite
 dimensional, finite, commutative, nozerodivisors, ... ).

 I think the above discussion gives good arguments why the ''factory'' for
 integer mod rings should not allow general freedom in the choice of a
 category: The factory needs to ensure uniqueness of instances. Some
 choices of a category play well with uniqueness: You want full sub-
 categories, and you want that containment in the sub-category does not
 rely on additional data (a ring intrinsically either is or is not a
 field). But other categories ''should'' result in a non-equal copy of the
 ring; for example, a Hopf algebra structure is not an intrinsic property
 and should thus not use a globally unique copy of a ring.

 Hence, the constructor of `IntegerModRing_generic` (or what's the name of
 the class?) should (and already does) of course accept a `category`
 argument. But here, we talk about the factory that manages quotients of
 the integer ring.

 I say: The factory should make it possible that the user asserts that the
 resulting ring is in fact a field, to avoid expensive primality tests.
 However, if you want to prescribe any fancy category for the resulting
 ring, you should either refine the category after the ring has been
 returned by the factory, or you should create a new factory (for quotient
 rings providing a fancy Hopf algebra structure) that is orthogonal to the
 `IntegerModRing` factory.

 In any case: Are there open questions from the discussion? AFAIK, the
 current branch addresses all questions. What is missing for a review?

--
Ticket URL: <http://trac.sagemath.org/ticket/15229#comment:55>
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