Proper parity check matrix handling

[Johan Rosenkilde]

In LinearCode parity check matrices are very much inferior to generator matrices: one can construct LinearCodes only by their generator matrix, and the parity check matrix will be computed in whatever form Sage finds suitable for returning the kernel of this generator matrix.

But codes can be defined by a (not necessarily full rank) parity check matrix, e.g. LDPC codes. Also, a code could have multiple, nice closed-form parity check matrix representations, and none of these can be expected to come out of as the kernel of any given generator matrix.

So we need to change somethings:

1. A LinearCode can be constructed by a parity check matrix
2. We introduce a registration system for parity check matrices similar to the encoder/decoder. LinearCode.parity_check_matrix takes an optional argument name for specifying which one you want. Obvious basic choices are unspecified (for just the kernel of a generator matrix), systematic. For some codes, such as Goppa codes, one could want the one coming from the Goppa equation, or the one coming from its Alternant code description.

The current implementation actually allows naming which Encoder's generator matrix is used for computing the kernel. Since the kernel computed by Sage for a given generator matrix is essentially a random basis for the kernel space (dual code), then I don't think this makes sense.

By the way, I have set the Milestone for this issue as "Cleanup LinearCode" because I think we shouldn't bother with it for Going Public.

Opinions?

[Johan Rosenkilde]

I just discovered that for a matrix M, then M.right_kernel() guarantees to give you a matrix in Echelon form. It seems it usually gives you one in Reduced Echelon form, but it is not indicated as a promise in the documentation.

[Daniel Augot]

I do not understand what you mean by systematic. I also find that unspecified is not clear.