Proper parity check matrix handling
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:
- A
LinearCode
can be constructed by a parity check matrix - We introduce a registration system for parity check matrices similar to the
encoder/decoder.
LinearCode.parity_check_matrix
takes an optional argumentname
for specifying which one you want. Obvious basic choices areunspecified
(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?
Comments (2)
-
reporter -
I do not understand what you mean by
systematic
. I also find thatunspecified
is not clear. - Log in to comment
I just discovered that for a matrix
M
, thenM.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.