Categories for IntegerMod rings

[nthiery]

After this patch, IntegerModRing?'s inherit properly from categories:

    sage: Z3 = IntegerModRing(3)
    sage: Z3.category()
    Category of commutative rings
    sage: TestSuite(Z3).run(verbose = True)
    running ._test_additive_associativity() . . . pass
    running ._test_an_element() . . . pass
    running ._test_associativity() . . . pass
    running ._test_category() . . . pass
    running ._test_elements() . . . 
      Running the test suite of self.an_element()
      running ._test_category() . . . pass
      running ._test_not_implemented_methods() . . . pass
      running ._test_pickling() . . . pass
      pass
    running ._test_not_implemented_methods() . . . pass
    running ._test_one() . . . pass
    running ._test_pickling() . . . pass
    running ._test_prod() . . . pass
    running ._test_some_elements() . . . pass
    running ._test_zero() . . . pass

And this makes the cool features from #7555 work for Z/nZ.

Potential conflict with #8218 (which has higher priority)

For a later ticket, see: running design discussion on:

​http://groups.google.com/group/sage-devel/t/21e21e1ec9cd21fe

[nthiery]

Ok, the tests passed fine up to some trivialities (*_with_category class name changes). I'll fix this and upload an updated patch soon. The review can start in parallel

[rbeezer]

This applies, builds and limited testing (prime and composite orders) indicates that it plays nicely with "addition tables" at #7555 which rely heavily on the category framework. Didn't run tests, but witnessed no problems otherwise.

Good to see how easy it is to insert a new object into the category framework.

I'll come back when the patch is completed.

[davidloeffler]

Just a heads-up: this looks rather like it might clash with #8218, which is the first of several patches by David Roe which do a substantial amount of work improving finite fields. #8218 has been held up for ages because it moves loads of files around (without substantially changing their content) so even small changes to finite fields will cause conflicts, and there is a lot of really good code waiting on it, so it would be a shame to have to put it off even longer.

David

[nthiery]

Replying to davidloeffler:

Just a heads-up: this looks rather like it might clash with #8218, which is the first of several patches by David Roe which do a substantial amount of work improving finite fields. #8218 has been held up for ages because it moves loads of files around (without substantially changing their content) so even small changes to finite fields will cause conflicts, and there is a lot of really good code waiting on it, so it would be a shame to have to put it off even longer.

Thanks for the notice. There is no urgency for that one, so sure, if there is any conflict, #8218 should go first.

David: I won't be touching this patch further. Feel free to update / refactor / merge /... it within the other series of patch whenever it feels right.

[nthiery]

David: I won't be touching this patch further. Feel free to update / refactor / merge /... it within the other series of patch whenever it feels right.

Note: I meant David Roe, but any other David is welcome too :-)

Oh: would you agree to take over that patch, and finalize it (or ping me) when it's ripe to get in?

(then I could forget about it).

[nthiery]

Replying to nthiery:

David: I won't be touching this patch further. Feel free to update / refactor / merge /... it within the other series of patch whenever it feels right.

Well, actually I did. But I should be done now, unless I notice a test failure.

[jhpalmieri]

Here's a rebased patch. It looks good and all tests pass for me so I'm willing to give it a positive review, but since I made the rebased patch, can someone else (Nicolas, for example) take a look at it also?

[nthiery]

Hi John!

Thanks much for rebasing the patch. I looked through the changes, and am happy to give my green light, up to three minor comments:

• Is the convention to use as ticket summary "trac 8562:" or "#8562:"? (I personally prefer the later).
• With the updated patch, sage -coverage complains because of the absence of #indirect doctest for create_object in sage/rings/finite_rings/integer_mod_ring.py. Just wanted to check; if this is voluntary, because you consider that this requires better tests, that's all fine with me.
• I like the options nodates=1 and showfunc = 1 of hg :-)

I let you set up the positive review as you feel appropriate.

Thanks again,

Nicolas

[jhpalmieri]

Replying to nthiery:

Is the convention to use as ticket summary "trac 8562:" or "#8562:"? (I personally prefer the later).

I think either is fine. I've been using "trac 8562" for a while and have not had any complaints from release managers.

• With the updated patch, sage -coverage complains because of the absence of #indirect doctest for create_object in sage/rings/finite_rings/integer_mod_ring.py. Just wanted to check; if this is voluntary, because you consider that this requires better tests, that's all fine with me.

This wasn't voluntary, it was an oversight. I'll fix it.

• I like the options nodates=1 and showfunc = 1 of hg :-)

Nice, I didn't know about those.

[jhpalmieri]

rebased version. apply only this patch.