Submodules of (ZZ/nZZ)^r

[wdjoyner]

This ticket add some support to submodules of (ZZ/mZZ)^r (e.g. containment, iteration). There is no new algorithm, we just use the code available for submodules of ZZ^r and the Schmidt normal form of integer matrix.

Follow up: #19345

CC: cesarnda@gmail.com @sagetrac-dlucas @johanrosenkilde

Component: linear algebra

Author: Vincent Delecroix

Branch/Commit: public/ticket/6452 @ c93a30a

Issue created by migration from https://trac.sagemath.org/ticket/6452

[wdjoyner]

applies to 4.1.alpha1

[wdjoyner]

comment:1

Attachment: trac_6452-codes-over-rings.patch.gz

This applies to 4.1.alpha1. This passed sage -testall except for

The following tests failed:                                                                             


        sage -t  "devel/sage/doc/fr/tutorial/programming.rst"
        sage -t  "devel/sage/sage/misc/darwin_utilities.pyx" 
Total time for all tests: 6017.1 seconds                     

Neither of these failures seem related to this ticket.

[aghitza]

comment:2

The patch doesn't contain the crucial file ring_code.pyx. Maybe you forgot to add this file to the hg repository?

[wdjoyner]

Attachment: trac_6452-ring-codes.patch.gz

ignore the previous patch; this applies to 4.1.2.rc2

[wdjoyner]

comment:3

This latest patch fixes some problems prointed out in private emails from Dan Gordon.

[wdjoyner]

comment:5

I can also say that the module in coding pass sage -t, with this patch applied, in OS 10.6 on an imac. OS10.6 does not pass sage -testall. However, I do have ubuntu 9.04 32bit installed under vmware on this machine and can test it there if desired.

[mwhansen]

comment:7

Is there any way we can get documentation for the cdef methods as well as possibly some more code comments? I'm just worried that there's no one who is able to maintain this code.

Also, it's not clear to me that there are not memory leak issues with this code as there are lots of malloc's and only one free.

[wdjoyner]

comment:8

If someone can explain to me what those functions will do, I will add comments on them.
As I said, I am basically doing a favor by posting a patch of someone else's code. I had to make a lot of additions to make it consistent with other parts of the codes library, but basically it is Cesar's code. Personally, I really don't understand the cython stuff.

Does this mean that the code will not be accepted?

[wdjoyner]

comment:9

Replying to @mwhansen:

Is there any way we can get documentation for the cdef methods as well as
possibly some more code comments? I'm just worried that there's no one who is
able to maintain this code.

Also, it's not clear to me that there are not memory leak issues with this
code as there are lots of malloc's and only one free.

As I said, I could try to add comments to the code, but I really don't know cython
nearly well enough to deal with malloc issues.

I've emailed Cesar and not gotten any response about the memory leak issues.

Given that, should the status change to "resolve as won't fix"? That would be too bad since Sage could really use "linear codes" over rings.

[fchapoton]

comment:42

this need a python3 refreshment, to avoid cmp and long

[embray]

comment:43

Tickets still needing working or clarification should be moved to the next release milestone at the soonest (please feel free to revert if you think the ticket is close to being resolved).

[embray]

comment:44

Ticket retargeted after milestone closed

[mkoeppe]

comment:45

Batch modifying tickets that will likely not be ready for 9.1, based on a review of the ticket title, branch/review status, and last modification date.

[mkoeppe]

comment:47

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[mkoeppe]

comment:48

Setting a new milestone for this ticket based on a cursory review.