Code engineering

The G-families produced under various generating mappings lend themselves to engineering a code for a specific purpose under specific constraints. For example, if given a dimension k and a desired capability of correcting t errors, the mapping $\ensuremath{f_{\mbox{\small lexi}}}$ can be used to generate an appropriate, approximately optimal code.

For a heuristic decoding optimization, the mapping $\ensuremath{f_{\mbox{\small trelli}}}$ may be used to generate an approximately optimal ``trellis-oriented'' code. These codes may be constrained further, however, if there is a particular memory limit m on the decoding space. In this case, the mapping $\ensuremath{f_{\mbox{\small state}}}$ may be used to get a reasonably short code satisfying dimension, error-correcting capability, and decoding memory constraints. Alternatively, one might wish to find a family of good codes with a bounded decoding time, in which case the mapping $\ensuremath{f_{\mbox{\small decoding}}}$ would be appropriate. In each of these cases, the G-construction, when possible, provides a code that meets the desired constraints and which, empirically, tends to have good parameters.

Appendix A lists various G-codes, demonstrating their use in this application. For example we see in Appendix A.1 that though the trellis-oriented codes have almost identical code parameters to their lexicode brothers, they tend to have a much better trellis complexity. As another example, we can see in Appendix A.2 that by sacrificing about 12% of the information rate, we can reduce decoding complexity from the 1024 states in the (38, 21, 8) lexicode to a mere 64 states in the (43, 21, 8) state-bounded code. Such a low memory requirement would be ideal for a VLSI chip or a smart card.