Project 12: Dual Space and Linear Functional Compiler

Build a compiler-like system that converts linear maps into dual and adjoint representations across bases and metrics, with pairing-invariance verification.

Quick Reference

Attribute Value
Difficulty Expert (Level 4)
Time Estimate 2 weeks
Language Python (alternatives: Haskell, Rust)
Prerequisites Linear maps, dual bases, inner products
Key Topics Dual map, pullback, adjoint, basis transformations

1. Learning Objectives

  1. Construct dual bases from arbitrary primal bases.
  2. Implement dual-map generation (T*) as composition on functionals.
  3. Implement adjoint generation under configurable metrics.
  4. Verify pairing invariance under basis changes.
  5. Separate transpose, dual, and adjoint semantics rigorously.

2. Theoretical Foundation

2.1 Core Concepts

  • Dual space V* as linear functionals on V.
  • Pullback map T*:W*->V* and arrow reversal.
  • Adjoint maps from inner-product relations.
  • Covector transformation laws under basis changes.

2.2 Why This Matters

Duality appears in gradients, constraints, normals, and co-state dynamics. Many implementation errors come from collapsing vectors and covectors without metric context.

2.3 Historical Context / Background

Dual-space formalism emerged with abstract linear algebra and became foundational in optimization, mechanics, and modern autodiff interpretation.

2.4 Common Misconceptions

  • Row vectors are inherently dual objects (they are coordinate representations only).
  • Transpose and adjoint are always identical.
  • Dual maps move in same direction as primal maps.

3. Project Specification

3.1 What You Will Build

A toolchain that ingests map/basis/metric definitions and emits:

  • Primal matrix representation
  • Dual map representation under dual bases
  • Adjoint representation under selected metrics
  • Pairing-invariance test report

3.2 Functional Requirements

  1. Parse map and basis specs.
  2. Compute dual basis from primal basis.
  3. Compute T* and T^dagger paths separately.
  4. Run randomized pairing consistency tests.
  5. Output symbolic derivation trace for auditability.

3.3 Non-Functional Requirements

  • Correctness: pairing identities must hold.
  • Clarity: output must explain conventions used.
  • Extensibility: support non-Euclidean metrics.

3.4 Example Usage / Output

$ python dual_compiler.py --map fixtures/T3.json --basis B,C --metric G
[INFO] primal matrix loaded (3x3)
[INFO] dual basis B* and C* computed
[INFO] dual map [T*] generated
[INFO] adjoint map [T^dagger] generated (metric-aware)
[PASS] pairing identity checks=200/200

3.5 Real World Outcome

You produce a verified duality engine suitable for graphics-normal transforms, constrained optimization tooling, and educational demonstrations of abstract map semantics.

4. Solution Architecture

4.1 High-Level Design

Spec Parser -> Basis/Dual Builder -> Map Transformer (dual/adjoint) -> Pairing Validator -> Reporter

4.2 Key Components

Component Responsibility Key Decisions
Basis Builder Construct primal and dual bases robust linear-solve backend
Dual Transformer Build T* via composition explicit convention registry
Adjoint Transformer Build metric-aware adjoint metric must be explicit
Validator Pairing identity checks randomized + symbolic fixtures
Reporter Trace derivations reproducible text output

4.3 Data Structures

DualCompileSpec:
  map_T
  basis_domain
  basis_codomain
  metric_domain
  metric_codomain

DualCompileReport:
  primal_matrix
  dual_matrix
  adjoint_matrix
  pairing_checks

4.4 Algorithm Overview

  1. Parse and normalize conventions.
  2. Compute dual bases and transformation matrices.
  3. Build dual map by functional composition.
  4. Build adjoint via metric relation.
  5. Validate pairing and report derivation chain.

5. Implementation Guide

5.1 Development Environment Setup

Install symbolic and numeric dependencies
Load basis/map fixture packs
Set deterministic test seed

5.2 Project Structure

P12/
  specs/
  basis/
  dual/
  adjoint/
  validate/
  reports/

5.3 The Core Question You’re Answering

“How do linear measurements transform when vectors change coordinates?”

5.4 Concepts You Must Understand First

  1. Dual basis definition and construction
  2. Pullback direction of dual maps
  3. Adjoint under non-identity metrics

5.5 Questions to Guide Your Design

  1. How will you prevent convention drift between modules?
  2. Which invariance checks catch transpose/adjoint confusion earliest?

5.6 Thinking Exercise

Hand-derive dual transform for a 2D non-orthonormal basis change. Compare with tool output and explain each matrix factor.

5.7 The Interview Questions They’ll Ask

  1. What is the conceptual difference between dual and adjoint maps?
  2. Why does dual map reverse direction?
  3. When can vectors and covectors be identified naturally?
  4. Why do normal vectors use inverse-transpose transforms?
  5. How does this relate to backpropagation?

5.8 Hints in Layers

  • Hint 1: Fix notation and conventions before coding.
  • Hint 2: Verify identity map behavior under all pathways.
  • Hint 3: Keep dual and adjoint computation APIs distinct.
  • Hint 4: Add symbolic sanity fixtures for small dimensions.

5.9 Books That Will Help

Topic Book Chapter
Dual spaces Axler Duality chapter
Adjoint operators Axler Operators chapter
Applied covector transforms graphics references normal transform sections

5.10 Implementation Phases

  1. Convention and spec system
  2. Dual-basis builder
  3. Dual-map compiler
  4. Adjoint compiler + validator

5.11 Key Implementation Decisions

  • Require explicit metric in adjoint path.
  • Emit derivation traces for every transform.

6. Testing Strategy

6.1 Test Categories

  • Exact symbolic fixtures
  • Random numeric fixtures
  • Non-Euclidean metric cases

6.2 Critical Test Cases

  1. Identity map under basis changes.
  2. Non-orthonormal basis with known dual basis.
  3. Metric where adjoint differs from transpose.

6.3 Test Data

  • Curated maps with expected dual/adjoint outputs.

7. Common Pitfalls & Debugging

  • Symptom: Pairing identity fails sporadically.
    • Why: Mixed basis convention between modules.
    • Fix: centralize convention metadata.
    • Quick test: identity map fixture.
  • Symptom: Adjoint equals transpose unexpectedly.
    • Why: metric matrix silently defaulted to identity.
    • Fix: make metric mandatory parameter.
    • Quick test: non-Euclidean metric fixture.

8. Extensions & Challenges

  • Add tensor-product duality support.
  • Add interactive derivation visualizer.
  • Integrate with autodiff graph tooling.

9. Real-World Connections

  • Normal transforms in graphics pipelines.
  • KKT and constrained optimization implementations.
  • Reverse-mode autodiff as pullback composition.

10. Resources

11. Self-Assessment Checklist

  • I can compute dual basis from first principles.
  • I can explain why T* reverses map direction.
  • My tool distinguishes transpose, dual, and adjoint outputs.
  • Pairing-invariance tests pass across basis changes.

12. Submission / Completion Criteria

  • Working dual/adjoint compiler with fixture coverage.
  • Pairing-invariance report with deterministic runs.
  • Short note explaining one real engineering use case.

This guide expands Project 12 from LINEAR_ALGEBRA_LEARNING_PROJECTS.md.