Code engineering

The $\mathfrak{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 $\mathfrak{G}$-construction often provides a code that meets the desired constraints and which, empirically, tends to have good parameters.

The appendix lists various $\mathfrak{G}$-codes, demonstrating their use in this application. For example we see in Appendix .1 that though the trellis-oriented codes have almost identical code parameters to their lexicode counterparts, they tend to have a much better trellis complexity. As another example, we can see in Appendix .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.