This software deals only with linear block codes for binary (ie,
modulo-2, GF(2)) vectors. The set of valid codewords for a linear
code can be specified by giving a *parity check matrix*,
**H**, with *M* rows and *N* columns. The valid
codewords are the vectors, **x**, of length *N*, for which
**Hx**=**0**, where all arithmetic is done modulo-2. Each row
of **H** represents a parity check on a subset of the bits in
**x**; all these parity checks must be satisfied for **x** to be
a codeword. Note that the parity check matrix for a given code (ie,
for a given set of valid codewords) is not unique, even after
eliminating rows of **H** that are redundant because they are
linear combinations of other rows.

This software stores parity check matrices in files in a sparse
format. These parity-check files are *not* human-readable
(except by using the `print-pchk`
program). However, they *are* readable on a machine with a
different architecture than they were written on.

Some LDPC software by David MacKay and others uses the alist format for parity check matrices. Two programs for converting between this format and the format for sparse parity check matrices used by this software are provided.

This software is primarily intended for experimentation with Low Density Parity Check (LDPC) codes. These codes can be constructed by various methods, which generally involve some random selection of where to put 1s in a parity check matrix. Any such method for constructing LDPC codes will have the property that it produces parity check matrices in which the number of 1s in a column is approximately the same (perhaps on average) for any size parity check matrix. For a given code rate, these matrices therefore become increasingly sparse as the length of a codeword, and hence the number of parity checks, increases.

Many methods for constructing LDPC matrices are described in the references. Two simple methods are currently implemented by this software, both of which operate according to the following scheme:

- Create a preliminary parity check matrix by one of the methods.
- Add 1s to the parity check matrix in order to avoid rows that have no 1s in them, and hence are redundant, or which have only one 1 in them, in which case the corresponding codeword bits will always be zero. The places within such a row to add these 1s are selected randomly.
- If the preliminary parity check matrix constructed in step (1) had an even number of 1s in each column, add further 1s to avoid the problem that this will cause the rows to add to zero, and hence at least one check will be redundant. Up to two 1s are added (since it is also undesirable for the sum of the rows to have only one 1 in it), at positions selected randomly from the entire matrix. However, the number of 1s to add in this step is reduced by the number already added in step (2). (Note that although redundant checks are not disastrous, they are better avoided; see the discussion of linear dependence in parity check matrices.)
- If requested, try to eliminate situations where a pair of columns both have 1s in a particular pair of rows, which correspond to cycles of length four in the factor graph of the parity check matrix. When such a situation is detected, one of the 1s involved is moved randomly within its column. This continues until no such situations remain, or until 10 passes over all columns have failed to eliminate all such situations.

The *evencol* method is the simplest way of performing step
(1) of the above procedure. For each column of the parity check
matrix, independently, it places a specified number of 1s in positions
selected uniformly at random, with the only constraint being that
these 1s be in distinct rows. Note that despite the name, the columns
do not have to have the same number of 1s - a distribution over
several values for the number of 1s in a column can be specified
instead. Such codes with different-weight columns are sometimes
better than codes in which every column has the same weight.

The *evenboth* method also puts a specified number of 1s in
each column, but it tries as well to keep the numbers of 1s in the
rows approximately the same. Initially, it creates indicators for all
the 1s that will be required, and assigns these 1s to rows as evenly
as it can, favouring earlier rows if an exactly even split is not
possible. It then assigns 1s to successive columns by selecting
randomly, without replacement, from this initial supply of 1s, subject
only to the constraint that the 1s assigned to a column must be in
distinct rows. If at some point it is impossible to put the required
number of 1s in a column by picking from the 1s remaining, a 1 is set
in that column without reference to other columns, creating a possible
unevenness.

Note that regardless of how evenly 1s are distributed in the preliminary parity check matrix created in step (1), steps (2) and (3) can make the numbers of 1s in the both rows and columns be uneven, and step (4), if done, can make the numbers of 1s in rows be uneven.

make-pchkpchk-file n-checks n-bits row:col ...

Creates a file named ` pchk-file` in
which it stores a parity check matrix with

**Example:** The well-known Hamming code with codewords of
length *N*=7 and with *M*=3 parity checks can be can be
created as follows:

alist-to-pchkalist-file pchk-file

Converts a parity check matrix in
alist
format stored in the file named ` alist-file` to
the sparse matrix format used by this software, storing it in the
file named

pchk-to-alistpchk-file alist-file

Converts a parity check matrix stored in the sparse matrix format
used by this software, in the file named ` pchk-file`, to
the alist
format, storing it in the file named

print-pchk [ -d ] [ -t ]pchk-file

Prints a human-readable representation of the parity check matrix stored
in ` pchk-file`.
The

The sparse display format consists of one line for every row of the matrix, consisting of the row number, a colon, and the column numbers at which 1s are located (possibly none). Row and columns numbers start at zero. No attempt is made to wrap long lines.

The dense display is the obvious array of 0s and 1s. Long lines are not wrapped.

**Example**: The parity check matrix for the Hamming code created
by the example for `make-pchk` would print
as follows:

make-ldpcpchk-file n-checks n-bits seed methodwhereis one of the following:methodevencolchecks-per-col[ no4cycle ] evencolchecks-distribution[ no4cycle ] evenbothchecks-per-col[ no4cycle ] evenbothchecks-distribution[ no4cycle ]

Creates a Low Density Parity Check matrix with
` n-checks` rows and

Two methods are currently available for creating the LDPC matrix,
specified by `evencol` or `evenboth`. Both methods
produce a matrix in which the number of 1s in each column is
approximately ` checks-per-col`, or varies from column
to column according the the

For both methods, the `no4cycle` option will cause cycles of
length four in the factor graph representation of the code to be
eliminated (if possible). A message is displayed on standard error if
this is not achieved.

A ` checks-distribution` has the form

Here,propxcount/propxcount/...

See the discussion above for more details on how these methods construct LDPC matrices.

**Example 1:** The `make-ldpc` command below creates
a 20 by 40 low density parity check matrix with three 1s per
column and six 1s per row, using random seed 1. The matrix
is then printed in sparse format
using print-pchk.

**Example 2:** The two `make-ldpc` commands
below both create a 20 by 40 low density parity check matrix with 30%
of columns with two 1s, 60% of columns with three 1s, and 10% of
columns with seven 1s. The transpose of the parity check matrix
is then printed in sparse format.

Back to index for LDPC software