Lattices

• Indefinite forms (mixed signature)
• Skew-symmetric forms
• Degenerate forms
• Hermitian sesquilinear forms

Gram vs Cartan Matrices

• Gram Matrix (G): G*{ij} = ⟨e_i, e_j⟩ for some basis {e_i}; symmetric; G*{ii} = -2 (our convention)
• Cartan Matrix (A): A*{ij} = 2⟨α_i, α_j⟩/⟨α_j, α_j⟩ for simple roots α_i; usually A*{ii} = 2, not symmetric in general
• Relation:
  • ADE types: A = -G
  • General types: Relation depends on root length ratios (BCFG, G₂ etc)

Orthogonality Behavior

• Symmetric forms: Orthogonality is symmetric, complements are well-defined
• Skew-symmetric forms: Every element is orthogonal to itself, no norm
• Non-symmetric forms: Distinction between left/right orthogonality, complements may not exist

Signature-Based Classification

• Convention: B*{ij} = 2 × cos(π/M*{ij}) (our Gram matrix)

• Definiteness criteria (inverted from literature):

• Classification (mathematically):
  • Elliptic/Finite: -G positive definite (i.e., B(v,v) < 0 for all nonzero v)
  • Parabolic/Affine: -G positive semidefinite with exactly one zero (i.e., B(v,v) ≤ 0)
  • Hyperbolic: -G indefinite, some B(v,v) positive, some negative

Definiteness is defined by the signs and behavior of B(v,v), not by eigenvalue analysis. This applies even for infinite modules, or over rings (ℤ, etc.), where spectral concepts do not apply. Always use algebraic and form-based criteria for classification—never rely solely on eigenvalue counts or numerical spectra.

Exact Arithmetic Principles

• Work over ℤ, ℚ, or exact rings. Never use floating point or ε comparisons for mathematical criteria.
• Eigenvalues/algebraic invariants are symbolic except for final visualization.

Field Extensions for Non-Crystallographic Types

• Crystallographic: ℤ, ℚ
• Non-crystallographic:
  • H₃: ℤ[φ] (φ² - φ - 1 = 0)
  • H₄: ℤ[τ] (τ = 2cos(π/5))
  • I₂(p): ℤ[2cos(π/p)]
• Always determine minimal field automatically; treat Galois orbits/invariants accordingly.

Implementation Advice (SageMath/Software)

• Do not use "inner product" for general bilinear forms in code or API.
• Always define matrix/data structures mathematically—don't guess or hard-code!
• Use symbolic computation for Gram matrices, never list notation or hard-coded lists (e.g., ['A', 2] is discouraged; use LaTeX 'A_2').
• For indefinite forms, use IntegralLattice (not IntegerLattice or Sage's length routines).
• Avoid algorithms that assume existence of orthogonal complements unless mathematically justified.
• Avoid floating-point epsilon comparisons at any stage.

Mathematical Pitfalls and Misconceptions

When reasoning about bilinear forms on free ℤ-modules:

• Many familiar vector-space definitions and operations are only mathematically valid in special cases:
  • The concept of orthogonal complement is only well-defined for symmetric (and sometimes skew-symmetric) forms. For a general bilinear form, orthogonality may not be symmetric or even meaningful as a submodule.
  • The function norm_squared (B(v,v)) only makes sense for symmetric forms. There is no notion of length or norm for a general bilinear form.
  • The reflection operation (across a subspace/module) only makes sense when the form is symmetric, as it depends on the geometric notion of orthogonality and norm.

Critical mathematical error: Extending the definitions of orthogonal complement, norm, reflection, and related concepts from vector spaces with inner products to general free ℤ-modules with bilinear forms can lead to incorrect mathematics. Only use these constructions when the underlying bilinear form and module structure mathematically warrant them.

References

See these for further mathematical and implementation guidance:

• /docs/api-planning/BILINEAR_FORMS_MATHEMATICAL_NOTES.md
• /docs/MATHEMATICAL_THEORY.md
• /docs/REQUIREMENTS.md
• /docs/api-planning/

Reminder: Mathematical definitions are primary. Implement algorithms based on mathematical structure (e.g. definiteness), not just eigenvalue counting.