#17287: K.is_subring(K) not implemented for some fields K
-------------------------------------+-------------------------------------
       Reporter:  mjo                |        Owner:  tmonteil
           Type:  enhancement        |       Status:  needs_review
       Priority:  major              |    Milestone:  sage-6.4
      Component:  algebra            |   Resolution:
       Keywords:  beginner           |    Merged in:
        Authors:  Akshay Ajagekar    |    Reviewers:  Michael Orlitzky
Report Upstream:  N/A                |  Work issues:
         Branch:                     |       Commit:
  u/ajagekar.akshay/Trac17287        |  2cb2f649aff4ff4b8b75e14c1beb0dc897dd91f3
   Dependencies:                     |     Stopgaps:
-------------------------------------+-------------------------------------
Changes (by mjo):

 * reviewer:   => Michael Orlitzky


Comment:

 So far so good! Whenever we fix a bug in sage, we like to add some tests
 to make sure that the bug is really fixed and won't come back again. In
 the description of this ticket, I found a few examples that used to fail
 but which now work. Can you add tests for those?

 You can see what a test looks like by looking at the commented code right
 above your fix:

 {{{
 EXAMPLES::

     sage: ZZ.is_subring(QQ)
     True
     sage: ZZ.is_subring(GF(19))
     False
 }}}

 I would suggest adding a new section called "TESTS" and placing the new
 tests there. The structure of our documentation strings is described in
 full at http://doc.sagemath.org/html/en/developer/coding_basics.html
 #documentation-strings. Here's what the first test would look like:

 {{{
 TESTS:

 Every ring is a subring of itself, :trac:`17287`::

     sage: QQbar.is_subring(QQbar)
     True
 }}}

 The :trac: thing is a special sort of link to this ticket, described in
 http://doc.sagemath.org/html/en/developer/sage_manuals.html#chapter-sage-
 manuals-links. Then you can add the other examples from the description
 below that. When you're done adding them, don't forget to run `sage -b` to
 build the changes (even though you only changed a comment). Then you can
 run the tests for that file with `sage -t`. Like,

 {{{
 $ sage -t sage/rings/ring.pyx
 Running doctests with ID 2016-01-31-09-08-05-2b1b6a12.
 Git branch: develop
 Using --optional=mpir,python2,sage
 Doctesting 1 file.
 sage -t --warn-long 72.5 sage/rings/ring.pyx
     [387 tests, 4.63 s]
 ----------------------------------------------------------------------
 All tests passed!
 ----------------------------------------------------------------------
 Total time for all tests: 4.9 seconds
     cpu time: 3.5 seconds
     cumulative wall time: 4.6 seconds
 }}}

 And it takes forever, but at least once, someone should run `make
 ptestlong` to test the entire sage library with the change in place.

--
Ticket URL: <http://trac.sagemath.org/ticket/17287#comment:5>
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 https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.

Reply via email to