# Coset Codes—Part I: Introduction and Geometrical Classification

**Date**: 03/08/2026
**Domain**: computer_science/information_theory
**Taxonomy**: academic/research_paper
**Filter**: Active comments

---

## Overall Feedback

Here are some overall reactions to the document.

**Coding Gain Definitions and Approximation Validity**

Readers might note inconsistencies in the fundamental coding gain definition between Section I-B and Section IV-B, particularly regarding normalization and parameter relationships. Additionally, the effective coding gain rule of thumb lacks theoretical justification and specified SNR operating ranges, affecting the rigor of performance comparisons. It would be helpful to clarify the equivalence conditions for fundamental gain formulations and provide bounds or citations for the effective gain approximation.

**Lemma 5 Proof Completeness and Invariance**

Lemma 5 claims equivalence between trellis codes based on different partitions, but the proof sketch does not fully establish that code sequences remain identical under the augmented encoder transformation. Furthermore, it does not explicitly address whether decoding complexity and error coefficients are preserved under this equivalence. It would strengthen the result to provide a more rigorous demonstration of sequence invariance and specify which performance parameters remain unchanged.

**Parameter Table Consistency and Data Completeness**

Several tables exhibit inconsistencies in depth parameter notation between real and complex definitions, and contain blank entries for error coefficients in new code classes. Additionally, the distance invariance assumption for new code classes is not explicitly verified against regular labeling conditions. It would be helpful to add footnotes clarifying depth conventions, complete the missing data entries, and confirm distance invariance for the proposed classes.

**Decoding Complexity Derivation and Verification**

The normalized decoding complexity values rely on an approximation range and algorithms detailed in a companion paper, making independent verification difficult. Since complexity is a key factor in the performance comparisons, the basis for these estimates affects the validity of the conclusions. It would be helpful to provide a sketch of the complexity analysis or specific references justifying the approximation range within this document.

**Scope Alignment and Practical Performance Context**

The Abstract suggests a universal framework for coding techniques, while the body restricts analysis to lattice-type coset codes, creating a scope tension. Moreover, performance comparisons exclude shape gain, which could mislead practical rankings for implementations where constellation shaping affects power efficiency. Aligning the Abstract to reflect the lattice-specific focus and adding caveats about shape gain would improve accuracy.

**Effective Coding Gain Approximation May Not Reflect Full Distance Spectrum**

The paper assumes effective coding gain γ_eff can be estimated using a rule of thumb (0.2 dB reduction per factor of 2 increase in error coefficient N₀), stated in Section V. However, actual error probability depends on the full distance spectrum, not just nearest neighbors. The paper acknowledges this is 'only approximately valid for moderately low error rates' and 'generally does not take into account neighbors other than the nearest' (Section VII). This affects Tables V, VII, VIII, IX, X, and XI where γ_eff values are used for code comparisons. Readers might note that codes with identical γ_eff could have different actual performance if their higher-order distance spectra differ. It would be helpful to provide uncertainty bounds on γ_eff values or include additional distance spectrum parameters (N₁, N₂) for more codes beyond the Ungerboeck-type codes where these are given in Table V.

**Decoding Complexity Values Reference External Algorithms**

The paper presents decoding complexity values N_D in Tables II, III, IV, VI, VII, VIII, IX, X, and XI, but these reference 'trellis-based decoding algorithms of part II' (the companion paper). Section III states complexity is 'measured by the number of binary operations of the trellis-based decoding algorithms given in part II.' Since Part II is not included in this document, readers cannot independently verify these complexity claims or understand the specific algorithm assumptions. This affects cross-paper comparisons and implementation planning. It would be helpful to include a brief summary of the complexity calculation methodology or provide a reference to publicly available implementation specifications that would allow independent verification of the N_D values.

**Status**: [Pending]

---

## Detailed Comments (21)

### 1. Variable n Overloading in Section I-B

**Status**: [Pending]

**Quote**:
> s) is equal to  $2r(\mathbb{C}) / N$ .
> 
> To transmit  $n$  bits per  $N$  dimensions, the signal constellation must consist of  $2^{n + r}$  points from a coset of  $\Lambda$ , partitioned into  $2^{k + r}$  subsets, each consisting of  $2^{n - k}

**Feedback**:
Readers might note that the variable $n$ is used for two different quantities: first as 'bits per $N$ dimensions' in the constellation size formula, then redefined as '$n = N / 2$' for the asymptotic coding gain formula. This overloading could cause confusion if a reader substitutes the bits-per-dimension value into the asymptotic gain formula. It would be helpful to rewrite the asymptotic gain formula to use a different variable (e.g., '$m = N/2$') to avoid ambiguity.

---

### 2. Rotation Operator R Terminology

**Status**: [Pending]

**Quote**:
> for our purposes is the rotation operator $R$, defined by the $2 \times 2$ matrix

**Feedback**:
The matrix R has determinant -2, not +1, so it cannot be a pure rotation operator. A proper rotation matrix must have determinant +1. The transformation actually combines scaling by √2 with a reflection. It would be helpful to rewrite 'the rotation operator R' as 'the scaled orthogonal transformation R (which rotates by 45° combined with a reflection)' to accurately characterize the transformation's determinant sign.

---

### 3. Integer Lattice Decomposition Excludes Negative Integers

**Status**: [Pending]

**Quote**:
> Z = \left[ Z / 2Z \right] + \left[ 2Z / 4Z \right] + \left[ 4Z / 8Z \right] + \cdots.

**Feedback**:
The equation claims that the lattice $Z$ is equal to the sum of coset representatives where coefficients $a_i \in \{0, 1\}$. This sum generates only non-negative integers, whereas the lattice $Z$ includes negative integers. Readers might note that negative integers cannot be formed by summing non-negative powers of 2 with binary coefficients. It would be helpful to specify that this decomposition applies to non-negative integers or adjust the representative sets to cover $Z$.

---

### 4. Sublattice Order Formula Fails for Negative Integers

**Status**: [Pending]

**Quote**:
> for any $m \in \mathbb{Z}$, the lattice $mZ^{N}$ of all $N$-tuples of integer multiples of $m$ is a sublattice of $Z^{N}$ of order $m^{N}$

**Feedback**:
The order (index) of a sublattice represents the number of cosets and must be a positive integer. The formula $m^N$ yields a negative value if $m$ is negative and $N$ is odd, which is impossible for a count of equivalence classes. It would be helpful to rewrite 'for any $m \in \mathbb{Z}$' as 'for any positive integer $m$' or change the order formula to '$|m|^N$' because the index must be non-negative.

---

### 5. Wrong Partition Index in Coset Decomposition

**Status**: [Pending]

**Quote**:
> $\phi a_1$ specifies the coset of $\phi^2 G$ in the partition $\phi G / \phi^3 G$

**Feedback**:
The partition index for $\phi a_1$ appears inconsistent with the chain $G / \phi G / \phi^2 G / \phi^3 G / \dots$. Each coefficient $a_k$ should specify a coset in $\phi^k G / \phi^{k+1} G$. Thus $\phi a_1$ should specify the coset in $\phi G/\phi^2 G$, not $\phi G/\phi^3 G$. It would be helpful to rewrite '$\phi G / \phi^3 G$' as '$\phi G / \phi^2 G$' to match the decomposition formula and maintain consistency with the partition chain.

---

### 6. Redundancy Definition Dimension Notation

**Status**: [Pending]

**Quote**:
> / 2^{m}Z^{N}|$ (resp. $|G^{N} / \phi^{n}G^{N}|$). The redundancy $r(\Lambda)$ of a binary lattice $\Lambda$ is defined as the binary logarithm of $|Z^{N} / \Lambda|$, so that $|Z^{N} / \Lambda| = 2^{r(\Lambda)}$. In view of the corolla

**Feedback**:
The redundancy definition uses $Z^N$ without distinguishing real from complex lattices. Earlier text states '$2N$ is the dimension of $\Lambda$ as a real lattice'. For a real $2N$-dimensional lattice, the ambient space is $Z^{2N}$, so redundancy should be $\log_2|Z^{2N}/\Lambda|$. It would be helpful to add clarification: 'For a real $2N$-dimensional binary lattice, $r(\Lambda) = \log_2|Z^{2N}/\Lambda|$; for a complex $N$-dimensional binary lattice, $r(\Lambda) = \log_2|G^N/\Lambda|$.'

---

### 7. Coset Representatives Cardinality Mismatch

**Status**: [Pending]

**Quote**:
> Thus the $2^{K}$ binary linear combinations $\{\sum a_{k}\mathbf{g}_{k}\}$ of the generators $\mathbf{g}_{k}$ are a system of coset representatives $[\Lambda_{k} / \Lambda_{k + 1}]$ for the partition $\Lambda_{k} / \Lambda_{k + 1}$

**Feedback**:
The partition $\Lambda_{k} / \Lambda_{k + 1}$ is explicitly defined as a 'two-way partition' in Lemma 2, meaning it has an index of 2 and exactly 2 cosets. However, the text claims the set of $2^{K}$ binary linear combinations serves as this system. For any $K > 1$, $2^{K} \neq 2$, creating a direct mathematical contradiction. It would be helpful to rewrite 'for the partition $\Lambda_{k} / \Lambda_{k + 1}$' as 'for the partition $\Lambda / \Lambda'$' because the full set of generators spans the entire chain.

---

### 8. Lemma 2 Endpoint Notation Inconsistency

**Status**: [Pending]

**Quote**:
> Then there is a sequence of lattices $\Lambda_0 = \Lambda$, $\Lambda_1, \dots, \Lambda_K \approx \Lambda'$

**Feedback**:
The lemma statement uses the approximation symbol $\approx$ for the final lattice $\Lambda_K$, implying it is only approximately equal to $\Lambda'$. However, the proof sketch explicitly states '$\Lambda_K = \Lambda'$ is certainly such a lattice.' In a mathematical definition of a partition chain, the endpoint must be exactly the sublattice $\Lambda'$. It would be helpful to rewrite '$\Lambda_K \approx \Lambda'$' as '$\Lambda_K = \Lambda'$' to match the proof sketch and standard lattice chain definitions.

---

### 9. Partition Chain Index Range Error

**Status**: [Pending]

**Quote**:
> Let $C_{\mu - 1} / C_{\mu - 2} / \dots / C_0$ be a partition chain of binary $(N, K_j)$ codes, $0 \leq j \leq \mu - 1$, i.e., $C_j$ is a subcode of $C_{j + 1}$.

**Feedback**:
The index range $0 \leq j \leq \mu - 1$ is incorrect for the statement '$C_j$ is a subcode of $C_{j+1}$'. When $j = \mu - 1$, this would require $C_{\mu-1}$ to be a subcode of $C_\mu$, but $C_\mu$ is not defined in the chain. It would be helpful to rewrite the index range as '$0 \leq j \leq \mu - 2$' to correctly specify when the subcode relationship applies.

---

### 10. Inconsistent Exponent Notation in Code Formula

**Status**: [Pending]

**Quote**:
>  are dual partition chains, and $\Lambda'^{\perp} / \Lambda^{\perp}$ is a partition of binary lattices with the same order and depth as $\Lambda / \Lambda'$.
> 
> If $\Lambda$ is a decomposable $N$-dimensional complex binary lattice of depth $\mu$, with code formula
> 
> $$
> \Lambda = \phi^ {n} \

**Feedback**:
The original lattice formula uses $\phi^n$ in the leading term while the depth parameter is consistently denoted as $\mu$ throughout the section. The examples confirm this: $D_4$ with depth 1 has $\phi G^2$ (i.e., $\phi^1$). For consistency, the original formula's leading term should be $\phi^{\mu} \boldsymbol{G}^N$ not $\phi^n \boldsymbol{G}^N$. It would be helpful to rewrite the first code formula with $\phi^{\mu} \boldsymbol{G}^N$ as the leading term to match the depth parameter $\mu$.

---

### 11. Undefined Exponent in Orthogonality Condition

**Status**: [Pending]

**Quote**:
> every generator $\phi^{\mu - j - 1} \pmb{g}_j^\perp$ of $\Lambda^\perp / \phi^n \pmb{G}^N$ is orthogonal mod $\phi^u$ to every generator

**Feedback**:
The orthogonality condition states generators are 'orthogonal mod $\phi^u$' but the exponent $u$ is never defined in this section. The depth parameter is consistently $\mu$ throughout, and the orthogonality should be modulo $\phi^{\mu}$ to match the lattice depth definition. It would be helpful to rewrite 'orthogonal mod $\phi^u$' as 'orthogonal mod $\phi^{\mu}$' and replace $\phi^n \pmb{G}^N$ with $\phi^{\mu} \pmb{G}^N$ in both quotient expressions.

---

### 12. Index Inconsistency in Code Partition Chain

**Status**: [Pending]

**Quote**:
> This proposition may be verified by noting that $C_0^\perp / \dots / C_{n-1}^\perp$ is a code partition chain

**Feedback**:
The code partition chain is written as $C_0^\perp / \dots / C_{n-1}^\perp$ but the lattice depth is $\mu$, so the codes should be indexed $C_0$ through $C_{\mu-1}$ as shown in the code formulas. The index $n-1$ should be $\mu-1$ for consistency. It would be helpful to rewrite $C_{n-1}^\perp$ as $C_{\mu-1}^\perp$ to match the depth parameter $\mu$ used in the code formulas.

---

### 13. Table I Lambda(0,4) Complex Code Formula Exponent Error

**Status**: [Pending]

**Quote**:
> Λ_{32} | 32 | 4 | 4Z^{32} + 2(32,26,4) + (32,6,16) | φ^{8}G^{16} + φ^{5}(16,15,2) + φ^{2}(16,11,4)

**Feedback**:
According to the general formula for Barnes-Wall lattices stated in the text: $\Lambda(0,n) = \phi^n G^N + \dots$ where $N = 2^n$. For $n=4$, $N=16$, the leading term should be $\phi^4 G^{16}$, not $\phi^8 G^{16}$. The depth $\mu = n = 4$ is correctly listed. The exponent 8 in the table contradicts the stated general formula. It would be helpful to rewrite the complex code formula as $\phi^4 G^{16} + \phi^3(16,15,2) + \dots$ to match the general Barnes-Wall lattice definition.

---

### 14. Table I Leech Lattice Complex Code Formula Exponent

**Status**: [Pending]

**Quote**:
> Λ_{24} | 24 | 4 | 4Z^{24} + 2(24,18,4) + (24,6,16)′ | φ^{8}G^{12} + φ^{5}(12,11,2)

**Feedback**:
The table lists depth $\mu = 4$ for $\Lambda_{24}$, and the text states 'for all of these lattices, the minimum squared distance $d_{min}^2(\Lambda)$ is equal to $2^\mu$'. For a depth-4 lattice, the leading term in the complex code formula should be $\phi^4 G^{12}$, not $\phi^8 G^{12}$. This is inconsistent with the Barnes-Wall lattice formulas where the leading exponent equals the depth. It would be helpful to rewrite the leading term as $\phi^4 G^{12}$ and adjust subsequent exponents accordingly to maintain the depth-4 structure.

---

### 15. Inconsistent Redundancy Definition in Table III Text

**Status**: [Pending]

**Quote**:
> its depth $\mu(\Lambda/\Lambda') = \mu(\Lambda')$, normalized informativity $\kappa(\Lambda/\Lambda') = \kappa(\Lambda')$, and normalized redundancy $\rho(\Lambda/\Lambda') = \rho(\Lambda)$

**Feedback**:
The text defines partition redundancy as dependent on the superlattice $\Lambda$, yet Table III lists multiple values for the same $\Lambda$. For instance, $D_8$ appears with $\rho=1/2, 1/4, 3/4$ in different rows. This suggests the definition should reference $\Lambda'$ instead to match the table data. It would be helpful to rewrite the definition to $\rho(\Lambda/\Lambda') = \rho(\Lambda')$ if consistent with all table entries.

---

### 16. Duplicate Partition Entries with Conflicting Parameters

**Status**: [Pending]

**Quote**:
> | 0 | 1 | 4 | 44 | 2.75  |
> |  E8 | RE8 | 8 | 16 | 3 | 1 | 1 | 4 | 8 | 60 | 3.75  |
> |  D8 | RE8 | 8 | 32 | 3 | 1 | 3/4 | 2 | 8 | 88 | 2.75  |
> |  D8 | RE8 | 8 | 128 | 3 | 1 | 1/4 | 2 | 8 | 280 | 2.2  |
> |  Z8 | RE8 | 8 | 256 |

**Feedback**:
Two rows list the same partition $D_8/RE_8$ but with different orders and redundancy values. Since the volume ratio determines the order, $\Lambda'$ cannot be identical in both cases. One entry likely has a typo in the lattice label or order column. It would be helpful to verify the intended sublattice for the second entry and correct the label or merge the rows if they are unintended duplicates.

---

### 17. Convolutional Code Algebraic Structure Terminology

**Status**: [Pending]

**Quote**:
> at the time shift of any codeword is a codeword, i.e., if $a(D)$ is a codeword, then so is $Da(D)$. (It follows that a convolutional code is a vector space over
> 
> the field of binary formal power series $f(D), f_{i} \in \{0,1\}$; the dimension of this vector space is $k$, and a

**Feedback**:
Formal power series $F[[D]]$ form a ring, not a field, because the delay operator $D$ does not have a multiplicative inverse within the set of formal power series. Since the text previously defines sequences with $t$ as any integer (positive or negative), the objects are Laurent series $F((D))$, which do form a field. It would be helpful to rewrite 'field of binary formal power series' as 'field of binary Laurent series' or 'ring of binary formal power series' to accurately reflect the algebraic structure.

---

### 18. Trellis Code Path Distance Calculation

**Status**: [Pending]

**Quote**:
> It is easy to see that the minimum squared distance between code sequences corresponding to distinct paths in the trellis is the minimum Hamming distance between sequences $c(D)$ of coset representatives and thus is equal to $d_H(C) = 5$.

**Feedback**:
Squared Euclidean distance is not equivalent to Hamming distance for this lattice mapping. For the standard 4-state error event (output bits 11, 01, 11), the mapped coset representatives are $(0,1), (1,1), (0,1)$ with squared norms 1, 2, 1, summing to 4. Additionally, the Hamming weight of these mapped 2-tuples is $1+2+1=4$, not 5. It would be helpful to rewrite 'is equal to $d_H(C) = 5$' as 'is 4 for the minimum weight error event' and clarify that Euclidean distance differs from bit-wise Hamming distance.

---

### 19. Volume Equation Contains Erroneous Intermediate Term

**Status**: [Pending]

**Quote**:
> Since $V(\mathbb{C}) = V(\Lambda_0) = 2^{-k(C)}V(\Lambda') = 2^{k+r}V(\Lambda') = 2^{r(C)}V(\Lambda)$, we also have the expressions

**Feedback**:
The equation chain contains an error in the third term. From the earlier derivation, $V(\Lambda_0) = 2^{-k}V(\Lambda')$ and $V(\Lambda') = 2^{k+r}V(\Lambda)$, so $V(\Lambda_0) = 2^{-k} \cdot 2^{k+r}V(\Lambda) = 2^r V(\Lambda)$. The term $2^{k+r}V(\Lambda')$ is incorrect. It would be helpful to rewrite the quoted text to remove the erroneous intermediate term $2^{k+r}V(\Lambda')$.

---

### 20. Coding Gain Formula Lacks Stated Assumption

**Status**: [Pending]

**Quote**:
> This last expression is the simplest and shows that we need to know only the minimum squared distance $d_{\min}^2(\mathbb{C})$ and the normalized redundancy $\mu(\mathbb{C})$ to compute the fundamental coding gain $\gamma(\mathbb{C}) = 2^{-\mu(\mathbb{C})}d_{\min}^2(\mathbb{C})$

**Feedback**:
The formula $\gamma(\mathbb{C}) = 2^{-\mu(\mathbb{C})}d_{\min}^2(\mathbb{C})$ is derived from the earlier expression only when $\gamma(\Lambda) = 1$ and $V(\Lambda) = 1$, which occurs when $\Lambda = G^N$. The text presents this as a general formula without clearly stating this critical assumption. It would be helpful to add 'when $\Lambda = G^N$' after the formula or add a clarifying sentence noting this restriction applies only to the baseline integer/Gaussian lattice case.

---

### 21. Dimensional Inconsistency in Table VI GCS-type Code

**Status**: [Pending]

**Quote**:
> | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
> |  4 | Z^{4} | 2Z^{8} | 8 | 3/4 | 1/2 | 4 | 2^{3/2} | 4.52 | 44 | 64 | 3.82  |
> 
> TABLE VII WE

**Feedback**:
The table lists N=4 with $\Lambda=Z^4$ (4-dimensional lattice), but $\Lambda'=2Z^8$ is an 8-dimensional lattice. For $\Lambda'$ to be a sublattice of $\Lambda$ in the partition $\Lambda/\Lambda'$, both must have the same dimension. Based on the Gallager code description in the text which uses $Z^4/2Z^4$, this should be $\Lambda'=2Z^4$. It would be helpful to rewrite the table entry with $\Lambda'=2Z^4$ to maintain dimensional consistency with the partition structure.

---
