Computations

Theorem 2.5 can be directly translated into an algorithm
that computes G-families. The algorithm simply computes the coset
leaders of *G*-codes in the family, from which the remaining
parameters may be easily deduced. This computation scheme has the
advantage of being dependent on the co-dimension (i.e. the dimension
of the dual code) rather than the dimension or the length alone.
Thus, this algorithm is efficient for high-rate codes, and it is
presented in Algorithm 2.12.

In Algorithm 2.12 we reuse our earlier notation that . Note that we assume that the coset leaders of the seed code are known or trivially derivable, as is often the case. The correctness of the algorithm follows immediately from Theorem 2.5. Moreover, we can also compute the running time and space of this algorithm in terms of

An oracle is simply a black box that computes a given function in constant time. In this case, we assume the existence of an oracle for computing the generating mapping because the complexity of such a computation can vary greatly among mappings. The proof of Lemma 2.13 follows from a straightforward analysis of the pseudo-code for Algorithm 2.12.

**Proof. **At each iteration, Algorithm 2.12 stores the coset
leaders of the code
which it is computing and the companion
of each leader. Thus, the algorithm requires space

The time bound for this algorithm, on the other hand, is somewhat more
complicated. Consider the innermost loop of the algorithm during
the computation of the *i*-th extension.
Clearly, based on Theorem 2.5, lines 6-10 are
executed at most once for each coset of
. Moreover, the
companion calculation in line 5 is executed once for each coset of
. The companion may be determined with a binary search
over coset syndromes; the binary search requires time:

Putting everything together, we get a running time of

O(2^{i}× i - 1 + n_{i}(i)) | O2^{i}in_{i} |

O(2^{i}in_{i}) |
O(n_{m}m2^{i}) |
||

O(n_{m}m2^{m}) |

This proves the lemma.

width4pt depth2pt height6pt

For the specific case of distance 4 lexicodes, this algorithm is particularly fast, since Brualdi and Pless [9, Thm.3.5] show that, under these circumstances:

m = n_{m} - 2 - log_{2}(n_{m} - 1) |
(9) |

so that Lemma 2.14 reduces to time

The analysis of Algorithm 2.12 assumes an oracle computation of the generating mapping. For the case of lexicodes and trellis-oriented lexicodes, however, Method 2.2 provides an efficient means of computing this mapping in time and constant space. As in the case of lexicodes and trellis-oriented codes, the overhead of computing is usually eclipsed by the running time of the remainder of the algorithm.

The complexity of Algorithm 2.12 is thus bounded by the co-dimension of the code and by the difficulty of computing the generating mapping. Under practical conditions, we were able to compute lexicodes well beyond length 44 initially reported in [14].

In addition, we were able to construct trellis-oriented codes with code parameters rivaling those of lexicodes, but with much better trellis state complexities. As an example, we generated trellis-oriented G-code with code parameters similar to lexicodes, but with better state complexity than the corresponding BCH codes heuristically minimized in [34]. These result were predicted by [34] and are demonstrated n Figures 2.7 and 2.8.

http://people.bu.edu/trachten