math-skill 2.0.1 → 2.1.0

package/skills/abstraction/SKILL.en.md

@@ -0,0 +1,117 @@
+---
+name: abstraction
+description: |
+  Trigger when extracting mathematical structures from complex problems, discovering cross-domain commonalities, building general theories; or finding transferable abstract structures (category/algebra/topology) for algorithm/operator design.
+---
+
+# 🧩 Abstraction
+
+> "The power of mathematics lies in abstraction: ignoring contingent details to reveal necessary structures."
+>
+> — Algebra, Topology, Category Theory
+
+## Core Principle
+
+**Abstraction is not distancing from reality but penetrating into it — by stripping away superficial, contingent details, one reveals deep, essential structures. Problems from different domains often share the same abstract structure.** In the context of this skill pack, abstraction is the core operation of "cross-domain activation": transferring structures from algebraic geometry / topology to algorithm design relies on identifying the abstract structures shared by both.
+
+Three progressive levels of abstraction: **Distillation** (identifying common structure across multiple instances) → **Generalization** (extending theorems from special to general cases) → **Structurization** (reconstructing the entire problem domain in the language of structure).
+
+> **Mathematical Formalization**
+>
+> Category-theoretic perspective: Objects and morphisms form a category **C**; functors **F, G : C → D** preserve structure; natural transformations **η : F ⇒ G** relate functors; **Yoneda Lemma**: Hom(Hom(−, A), F) ≅ F(A), i.e., an object is completely determined by all morphisms pointing to it.
+>
+> Algebraic perspective: Groups (closure, associativity, identity, inverse); rings (additive group + multiplicative semigroup + distributivity); fields (ring + multiplicative inverses); modules (vector spaces over a ring); lattices (partially ordered set + meet and join).
+
+## GPU-Friendliness (Cross-Cutting Check)
+
+Whether an abstract structure can be deployed on GPU depends on the computational form it takes once "concretized" — pass the eight dimensions of `../../references/gpu-friendly-math.md`:
+
+- **Category / algebraic structure → GEMM**: If the abstract structure can be concretized as linear maps (e.g., restriction maps, group representations), it naturally maps to Tensor Core GEMM (friendly).
+- **Universal constructions (products / coproducts / limits)**: If materialized as large intermediate tensors, memory explodes (unfriendly) → refactor into chunked / streaming or low-rank approximations.
+- **Yoneda perspective**: Replace internal structure with Hom-behavior — if the Hom-sets themselves are huge, the construction is non-computable; friendly only when Hom can be batch-tensorized.
+- **Anti-pattern**: Forcing an essentially discrete/symbolic abstraction (e.g., exact computation of general cohomology) into training is often "beautiful but not computable."
+
+Eight-dimension minimum assessment (formal terminology): **Tensorization** — whether abstract objects can be concretized as batched tensors; **GEMM-Mappability** — whether morphisms / representations / restriction maps can reduce to linear maps; **Complexity** — whether the abstraction layer introduces super-linear global constructions; **Memory & KV-Cache** — whether products / limits / Hom tables are materialized; **Low-Precision Stability** — whether concretization depends on ill-conditioned inversion or exact symbolic equalities; **Parallelism & Communication** — whether the construction is locally block-decomposable; **Sparsity Structure** — whether it yields block/banded structure rather than random access; **Operator Fusion** — whether abstract interfaces can converge into a small number of fused kernels.
+
+> In conjunction with `../../references/books/algebraic-geometry-rising-sea.md`, `abstract-algebra.md`, `smooth-manifolds.md`.
+
+## When NOT to Use
+
+- **Every detail is critical** (e.g., debugging a specific bug) — abstraction would discard key information.
+- **A specific numerical answer is needed** (e.g., "what is this integral equal to") — abstraction does not provide concrete calculations.
+- **The problem is already in its simplest form** — no further abstraction is needed.
+
+## When to Use
+
+- When facing a complex problem and not knowing where to start — first abstract out the core structure.
+- When two seemingly different problems share similarities — seek a common abstract framework.
+- When generalizing specific experience into general rules, or building cross-domain general models/theories.
+- **Transferring modern math structures to algorithm/operator design** — identifying the abstract structure the problem shares with algebraic geometry / topology / Lie theory.
+
+## Method
+
+### Step 1: Describe the Concrete Problem
+Precisely describe all elements of the problem in mathematical language — objects, relations, constraints, objectives. Abstraction begins with the concrete: before abstracting, one must fully understand the concrete objects.
+
+### Step 2: Distinguish Essential from Non-Essential Features
+Examine each feature one by one: if this feature is changed, does the core structure of the problem change? **Essential features** (those whose change fundamentally alters the nature of the problem) must be retained; **non-essential features** (those whose change leaves the structure invariant) can be ignored. Example: when studying matrix invertibility, the specific entries are non-essential (invariant under similarity transformations), while rank is essential.
+
+### Step 3: Extract the Abstract Structure
+Choose the best-matching perspective from four mathematical viewpoints and execute its operations:
+
+- **Category-theoretic perspective** (focus on relations between objects): Identify "objects" and "morphisms/relations"; check that morphisms compose and have identities → forming a category; further check for functors to known categories, natural transformations relating different functors.
+- **Algebraic perspective** (focus on operations and axioms): Identify "operations" and their properties (closure / associativity / commutativity / distributivity); match axioms against group / ring / field / module / lattice; determine the best-matching structure.
+- **Topological perspective** (focus on continuity and connectedness): Identify "continuous change / proximity / connected-separated"; construct open-set structure and verify topological axioms; identify topological invariants (connectedness, compactness, fundamental group).
+- **Analytic perspective** (focus on metrics and norms): Identify "distance / size / convergence"; verify metric/norm axioms; determine properties such as completeness/boundedness, and invoke the corresponding theorems (e.g., Banach space theory).
+
+### Step 4: Solve at the Abstract Level
+Leverage existing theory of the abstract structure. Key tools:
+- **Universal constructions**: Products (unified projections), coproducts (unified embeddings), limits/colimits (merging and gluing under compatibility conditions).
+- **Yoneda Lemma insight**: An object is completely determined by all morphisms pointing to it; to understand X, examine Hom(A,X) / Hom(X,A); to prove two objects are isomorphic, it suffices to show their morphism behavior is identical.
+
+### Step 5: Concretize Back
+Precisely translate each element of the abstract solution back into the mathematical language of the original problem, ensuring every step has a correspondence. After abstraction, one must return to the concrete; otherwise abstraction loses its meaning.
+
+### Step 6: Verify
+Is key information fully preserved through the round trip? Does the answer to the original problem have a clear counterpart in the abstract solution? After translating back to the concrete, does it indeed solve the original problem? Has any essential feature been accidentally overlooked?
+
+### Step 7: Level Progression
+- **Distillation → Generalization**: When the distilled concept has been verified across multiple instances, and the theorem's natural extension appears to hold under broader conditions → generalize.
+- **Generalization → Structurization**: When generalized theorems have accumulated enough to support a self-consistent system, and different generalizations are systematically related → structurize.
+- **No premature leaps**: If distilled concepts have not been verified across enough instances, do not rashly generalize; if generalized theorems are scattered and unsystematic, do not rashly structurize.
+
+## Common Errors
+
+| Error | Critique | Correct Approach |
+|---|---|---|
+| Over-abstraction | Abstracting away essential details, distorting the problem (e.g., dropping group inverses and retaining only a semigroup) | After each abstraction, check whether key information is preserved |
+| Under-abstraction | Retaining too many non-essential details, failing to achieve simplification | Repeatedly ask: is this detail truly necessary? |
+| Abstracting to the wrong level | Using category theory for a problem that only needs group theory; or using only set theory for a problem with group structure | Choose the level matching the problem's complexity |
+| Forgetting the functorial perspective | Looking only at internal object structure while ignoring morphisms, losing half the information | Simultaneously examine Hom(A,X) and Hom(X,A) |
+| Forgetting to return to the concrete | Staying at the abstract level without translating back to the original problem | After abstraction is complete, concretization is mandatory |
+| Abstract structure is non-computable | Forcing an essentially discrete/symbolic abstraction into GPU training | After concretization, pass the GPU eight-dimension gate; if non-computable, adapt or abandon |
+
+## Operating Procedure
+
+When this skill is triggered, the output must contain:
+
+1. **[Problem Description]:[Concrete]** — Precisely describe all elements of the problem in mathematical language
+2. **[Essential / Non-Essential]:[Distinction]** — List essential and non-essential features, annotating for each whether changing it affects the core structure
+3. **[Perspective Choice]:[One of Four]** — Select the best match from category-theoretic / algebraic / topological / analytic, and execute its operational steps
+4. **[Abstract Solution]:[Construction]** — Using universal constructions or the Yoneda perspective, provide a solution direction at the abstract level
+5. **[Concretization]:[Translation]** — Precisely translate the abstract solution back into the mathematical language of the original problem
+6. **[Verification]:[Check]** — Is key information fully preserved through the round trip?
+7. **[Level Assessment]:[Progression]** — Indicate which level (distillation / generalization / structurization) is current, and assess whether a leap is warranted
+8. **[GPU Feasibility]** (if used for algorithm/operator design) — After concretizing the abstract structure, pass the eight-dimension gate, rating friendly / retrofittable / unfriendly
+
+**Output must never provide analysis alone without a conclusion.**
+
+## Relations to Other Skills
+
+- **Axiomatization**: Abstraction is the precursor to axiomatization — first abstract the essentials, then choose the axioms.
+- **Modeling**: Modeling is the concrete application of abstraction — abstracting real-world problems into mathematical ones.
+- **Transformation**: A transformation can be seen as a form of abstraction — finding simple structure in a new representation.
+- **Induction and Analogy**: Analogy is essentially identifying the shared abstract structure between two different domains.
+- **Topological Thinking**: Topological abstraction focuses on continuity and connectedness; it is the concrete form of abstraction in spatial problems.
+- **Algorithmic Thinking**: Algorithmic abstraction focuses on the structure of computational processes, abstracting concrete implementations into algorithmic patterns and complexity classes.
+- **Modern Math Activation**: `../../references/books/algebraic-geometry-rising-sea.md` (sheaves/categories → attention), `abstract-algebra.md` (groups/semirings → equivariance and routing), `smooth-manifolds.md` (manifold structure → latent-space geometry).

package/skills/abstraction/SKILL.md

@@ -5,6 +5,8 @@ description: |
   English: Trigger when extracting mathematical structures from complex problems, discovering cross-domain commonalities, building general theories; or finding transferable abstract structures (category/algebra/topology) for algorithm/operator design.
 ---
 
+> **语言路由**：若用户消息为英文，请读取并遵循同目录下的 `SKILL.en.md`，按其操作规程以英文输出；中文消息则继续使用本文件。
+
 # 🧩 抽象化思想 / Abstraction
 
 > "数学的力量在于抽象：忽略偶然细节，揭示必然结构。"

package/skills/abstraction/original-texts.en.md

@@ -0,0 +1,163 @@
+# Mathematical Sources and Classic Texts
+
+## Galois Theory (1830s)
+
+> "The profundity of Galois theory: it transforms the question 'can an equation be solved by radicals?' into the structural question 'is the permutation group solvable?'"
+
+**Abstract paradigm**: Galois theory represents the earliest systematic abstraction in the history of mathematics — rising from concrete equation-solving to the symmetry structure of groups.
+- The permutation group of roots determines the solvability of an equation
+- The Galois correspondence: subgroups ↔ subfields, directly linking algebra to structure
+- Far-reaching influence: inaugurated the mode of thinking "replace calculation with structure," laying the foundation for abstract algebra
+
+**History**: Évariste Galois (1811–1832), unrecognized during his lifetime; his manuscripts were published by Liouville in 1846.
+
+## Dedekind & Noether — From Numbers to Structures
+
+> "Dedekind abstracted integers from 'counting tools' into 'ideals of rings'; Noether systematized this, making ideals the central objects of algebra."
+
+**Key contributions**:
+- **Dedekind (1831–1916)**: Founder of ideal theory — abstracted "divisibility" into "containment relations," elevating number theory to a structural level
+- **Emmy Noether (1882–1935)**:
+  - Noetherian rings: the ascending chain condition abstracts "finiteness" from concrete objects to a structural property
+  - Noether's theorem (1918): symmetries ↔ conservation laws in physics — a paradigm of abstract structure in physics
+  - Transformed abstract algebra from a "computational" to a "structural" discipline
+
+> "Noether's teaching mode: 'Es steht schon bei Dedekind' (Dedekind already wrote it) — she always traced ideas back to their structural origins."
+
+## Category Theory (Eilenberg & Mac Lane, 1945)
+
+> "The key idea of category theory: studying the morphisms (maps) between objects is more important than studying the objects themselves."
+
+**Core concepts**:
+- **Objects** and **Morphisms**
+- **Functors**: Maps between categories
+- **Natural Transformations**: Maps between functors
+- **Universal Properties**: Defining objects through their relations
+
+**The significance of abstraction**: Category theory is "the mathematics of mathematics" — it is abstract enough to describe the structure of mathematics itself.
+
+## Yoneda Lemma (1954)
+
+> "An object is completely determined by its relationships to all other objects — this is the fundamental theorem of category theory."
+
+**Mathematical meaning**:
+- Formal statement: Hom(Hom(A, —), F) ≅ F(A) — there is a one-to-one correspondence between natural transformations of a functor and the functor's evaluation at A
+- Philosophical significance: To understand a thing, one need only observe its interactions with everything else — "you are defined by your relationships"
+- The Yoneda embedding: every object A ↦ Hom(—, A); an object can be fully embedded into its "relational world"
+- Called the "first theorem" of category theory, its status is analogous to the axiom of extensionality in set theory
+
+**History**: First appeared in Nobuo Yoneda's unpublished notes, later formally expounded by Mac Lane in 1954.
+
+## Bourbaki (1935–)
+
+> "Bourbaki rewrote 20th-century mathematics with 'structures' as a unifying language — from mother structures (algebra, order, topology), everything is structure."
+
+**Core ideas**:
+- Three mother structures: algebraic, order, and topological
+- Multiple structures: formed by combining mother structures — topological groups, ordered fields, etc.
+- *Éléments de mathématique*: a systematic rewrite spanning over 40 volumes
+- Far-reaching influence: defined the organizational structure and abstract style of modern mathematics textbooks
+
+**Controversy**: Bourbaki's structuralist bias was excessively abstract, neglecting probability theory and computational mathematics — yet it was precisely this drive toward abstraction that catalyzed the birth of category theory.
+
+## Algebraic Structures
+
+Abstract algebra reveals deep commonalities among diverse mathematical objects:
+
+| Structure | Operational Requirements | Examples |
+|-----------|-------------------------|----------|
+| Semigroup | Closure, associativity | Function composition, string concatenation |
+| Monoid | Semigroup + identity element | Natural number addition, list concatenation (including the empty list) |
+| Group | Monoid + inverses | Symmetric groups, the additive group of integers |
+| Ring | Group (addition) + semigroup (multiplication) + distributivity | The ring of integers, polynomial rings |
+| Field | Ring + multiplicative inverses (for nonzero elements) | The field of rationals, the field of reals |
+| Vector Space | Additive group over a field + scalar multiplication | ℝⁿ, function spaces |
+
+**The significance of intermediate structures**: Semigroups and monoids are not "incomplete groups" — in automata theory, formal languages, and string processing, they are themselves the central objects. Abstraction does not seek the "most complete" structure but extracts precisely the properties that are needed.
+
+**The power of abstraction**: Once a theorem is proved at the abstract level, it automatically applies to all instances satisfying that structure.
+
+## Universal Algebra (Birkhoff, 1935)
+
+> "The central question of universal algebra: which equational classes can be defined by a set of equational axioms?"
+
+**Key contributions**:
+- **Birkhoff's Theorem**: A class of algebras is a variety if and only if it is closed under homomorphic images, subalgebras, and direct products (the HSP Theorem)
+- Systematic study of "algebraic structures as such" — not a particular group or ring, but "the common properties of all structures satisfying given axioms"
+- Universal algebra as a precursor to category theory: concepts such as universal properties and free objects already had their prototypes here
+- Relationship to category theory: equational classes = universal objects in the category generated by free algebras
+
+## Representation Theory (Frobenius, 1896–)
+
+> "Representation theory 'realizes' abstract groups as concrete linear transformations — making invisible symmetries visible."
+
+**Core ideas**:
+- Group representation: a group G → GL(V), mapping abstract group elements to matrices
+- Frobenius (1849–1917): Pioneered character theory of groups, using trace functions to capture irreducible representations
+- Irreducible representations: the "atoms" of a group — all representations are built from them
+- Schur's Lemma, Maschke's Theorem, and related results form the complete theory of semisimple algebras
+
+**The dual significance of abstraction**: On one hand, representation theory makes abstract objects computable; on the other hand, the classification of representations is itself a higher-level abstract problem.
+
+## Free Objects and Universal Constructions
+
+> "A free object is the most general object with 'no extra relations' — determined only by relations forced by axioms."
+
+**Core concepts**:
+- **Free group**: Generated by an alphabet, with no extra relations beyond the group axioms
+- **Free monoid**: Simply the set of strings — string concatenation is the "freest" associative operation
+- **Universal property formulation**: A free object F(A) satisfies the property that any map A → X (where X is an object in the target structure) extends uniquely to a morphism F(A) → X
+- **Left adjoint**: The left adjoint of the forgetful functor is precisely the free object — the "most general solution" of abstraction
+
+**Significance**: Free objects exemplify the paradigm of universal constructions — defining the "most general solution" with "the fewest constraints," then obtaining more specific objects by imposing additional relations.
+
+## Grothendieck & Schemes (1950s–60s)
+
+> "Grothendieck completely reconstructed algebraic geometry: no longer studying specific curves, but schemes — the most general notion of 'space'."
+
+**Revolutionary abstraction**:
+- **Schemes**: Generalized algebraic varieties to allow zero divisors and arbitrary base changes — "space" is no longer a point set but the spectrum of a ring
+- **Topoi**: A notion of "space" more general than topological spaces — a topos is a category rich enough to support an internal logic
+- **Motives**: The conjectural "universal cohomology theory" — the common root of different cohomology theories
+- **Universal construction philosophy**: Grothendieck always sought the "most general" framework first, then solved specific problems within it
+
+**Impact**: The EGA/SGA rewrite, spanning over four thousand pages, made algebraic geometry one of the most abstract yet most powerful branches of mathematics. The proof of the Weil conjectures was a direct fruit of this abstract framework.
+
+## Topology
+
+> "Topology studies properties that remain unchanged under continuous deformations."
+
+**Levels of abstraction**:
+- Metric space → topological space: discard distance, retain only the notion of "open sets"
+- Continuous functions → morphisms: discard ε-δ, retain only "the preimage of an open set is open"
+- Homeomorphism → equivalence: spaces that are "the same" in the topological sense
+
+**Classic example**: A coffee cup and a donut are homeomorphic in the topological sense — they both have exactly one hole.
+
+## Homotopy Type Theory (Voevodsky, 2009–)
+
+> "The univalence axiom of homotopy type theory asserts: isomorphic structures are identical — the ultimate form of abstraction."
+
+**Core ideas**:
+- **Univalence Axiom**: (A ≃ B) ≃ (A = B) — isomorphism and equality are equivalent
+- Philosophical impact: if two structures agree on all observable properties, they "are" the same — there is no "unobservable" identity
+- **Homotopy levels (h-levels)**: Propositions (h-level 1), sets (h-level 2), group objects (h-level 3), ... — unifying classical logic with topological intuition
+- Voevodsky (1966–2017): Fields Medalist who devoted his later career to establishing mathematics on a new foundation with greater computational reliability
+
+**Relationship to category theory**: Homotopy type theory can be viewed as the "internal language" of category theory — in the context of (∞,1)-categories, the univalence axiom arises naturally.
+
+## The Nature of Abstraction
+
+> "Abstraction means ignoring specific, contingent features and extracting general, essential structures."
+
+Abstraction is not a retreat from reality but a deeper engagement with it — by identifying the common structure underlying different phenomena, we can treat them within a unified framework.
+
+**The genealogy of abstraction**:
+- Galois (1830s): equations → group structure
+- Dedekind (1870s): numbers → ideals
+- Birkhoff (1935): concrete algebras → equational classes
+- Eilenberg–Mac Lane (1945): concrete mathematics → categories
+- Grothendieck (1960s): concrete spaces → schemes and topoi
+- Voevodsky (2010s): isomorphism → identity
+
+Each step of abstraction reveals deeper structure and enables us to address a broader class of problems.

package/skills/algorithmic-thinking/SKILL.en.md

@@ -0,0 +1,132 @@
+---
+name: algorithmic-thinking
+description: |
+  Trigger when a problem needs finite-step solving, algorithm design, complexity analysis (time/space), tractability & parallelism assessment (P/NP-hard/undecidable); or termination/correctness proofs; or designing executable algorithms/operators for GPU (assessing complexity order, parallelism, memory access & fusion).
+---
+
+# 🖥️ Algorithmic Thinking
+
+> "An algorithm is the automation of thought — turning insight into precisely repeatable steps."
+>
+> — Computability Theory, Algorithm Analysis, Complexity Theory
+
+## Core Principle
+
+**Break problems into executable steps, assess cost, judge feasibility. The first principle is not "how to solve" but "whether it is solvable and at what cost" — some problems are inherently hard (NP-complete), some inherently unsolvable (undecidable); knowing these limits is as important as finding solutions.**
+
+> **Mathematical Formalization**
+>
+> A Turing machine M: Σ* → Σ* halts within a finite number of steps. Time complexity T(n) = the maximum number of execution steps for an input of length n; space complexity S(n) = the maximum number of cells used. Church–Turing thesis: anything computable is computable by a Turing machine.
+>
+> Three-tier hierarchy: computable (an algorithm exists) → tractable (a polynomial-time algorithm exists) → intractable (only exponential-time or no algorithm). Computable but intractable is practically equivalent to uncomputable — brute force 2^n is worthless for n=100. P vs NP is precisely the boundary between tractable and intractable.
+>
+> Complexity notation: O(f(n)) upper bound, Ω(f(n)) lower bound, Θ(f(n)) tight bound. Common recurrences: T(n)=2T(n/2)+O(n) → O(n log n); T(n)=T(n-1)+O(n) → O(n²); T(n)=T(n/2)+O(1) → O(log n). Complexity classes: O(1) ⊂ O(log n) ⊂ O(n) ⊂ O(n log n) ⊂ O(n^k) ⊂ O(2^n) ⊂ O(n!).
+>
+> Complexity class definitions: P = polynomial-time decidable; NP-hard = at least as hard as every problem in NP; undecidable = no algorithm can decide it. NP-hard response: approximation (with error bounds) or heuristics (with probabilistic guarantees); undecidable response: find a decidable restricted version.
+>
+> Loop invariant: a property that holds before and after every iteration, which together with the termination condition implies output correctness. Hoare logic: {P} S {Q} — precondition P, after statement S, yields postcondition Q.
+
+## GPU-Friendliness (Cross-Cutting Check)
+
+Algorithmic thinking is the weapon most directly relevant to GPU — complexity order, parallelism, memory access/communication, and operator fusion directly determine whether an algorithm can run efficiently on GPU. Every algorithm must pass the `../../references/gpu-friendly-math.md` eight-dimension gate:
+
+- **Complexity order**: Sub-quadratic O(n log n)/O(n) is friendly (fully utilizes parallel cores); O(n²) is borderline (GEMM is an exception, salvageable by Tensor Cores); O(2^n)/O(n!) is an anti-pattern.
+- **Parallelism and communication**: Divide-and-conquer / data parallelism is friendly (sub-problems are independent, batchable); dependency chains in dynamic programming and serial search in backtracking require adaptation (chunking / skew scanning).
+- **Memory and KV-Cache / Parallelism and communication**: Coalesced access is friendly; butterfly reductions and prefix scans have dependency patterns that require attention to bandwidth; random scatter/gather is unfriendly.
+- **Operator fusion**: Multiple elementwise steps can be fused into a single kernel; algorithms that repeatedly read/write to memory — "beautiful but intractable" — should be rearranged into a single pass.
+
+Eight-dimension minimum criteria (formal terms): **Tensorization** requires the main loop to be batchable; **GEMM-mappability** prioritizes expressing the core computation as GEMM/conv/scan; **complexity** must specify both time and space order; **memory and KV-cache** checks whether intermediate tables, state, and cache can be chunked; **low-precision stability** checks reduction, sorting, and iteration errors; **parallelism and communication** checks dependency graphs and cross-device synchronization; **sparse structure** accepts only structured sparsity; **operator fusion** requires reducing small kernels and memory round-trips.
+
+| Algorithm characteristic | GPU classification | Notes |
+|---|---|---|
+| Divide-and-conquer / Merge / FFT | Friendly | Sub-quadratic, batchable, regular structure |
+| Dynamic programming (dependency chains) | Adaptable | Chunking / skew scanning breaks serial dependencies |
+| Backtracking / DFS serial search | Anti-pattern | Unpredictable branching, cannot fill SIMD lanes |
+| Brute force O(2^n) | Anti-pattern | Complexity order itself is intractable |
+
+> Used together with `../../references/books/matrix-analysis.md` (GEMM / low-rank decomposition for order reduction), `../../references/books/optimization-ml.md` (first-order / second-order method feasibility), `../../references/books/abstract-algebra.md` (parallel algorithms over semirings / finite fields).
+
+## When NOT to Use
+
+- **The problem has a closed-form solution and does not require step-by-step computation** — e.g., the quadratic formula directly gives the answer; algorithmic treatment only adds complexity.
+- **The problem is qualitative rather than procedural** — e.g., "Is this structure elegant?" or "Is this proof insightful?" cannot be reduced to finite steps.
+- **The input is unstructured and cannot be discretized** — e.g., a continuous perceptual data stream cannot directly serve as algorithm input; when preprocessing is more complex than the core problem, algorithmic treatment may not be optimal.
+
+## When to Use
+
+- Automating a repetitive process — the same operation must be performed on large volumes of data; manual execution does not scale.
+- Verifying program termination — proving the algorithm halts in a finite number of steps is the cornerstone of reliability.
+- Estimating computational cost — evaluating time/space consumption before large-scale runs to avoid resource exhaustion.
+- Facing combinatorial explosion — the search space grows exponentially with input size, requiring pruning strategies.
+- Judging problem feasibility — determining P / NP-hard / undecidable to decide on a solution strategy.
+- Designing efficient solution procedures — from brute force to elegant algorithms, efficiency differences can span several orders of magnitude.
+- **Designing executable algorithms/operators for GPU** — assessing complexity order, parallelism, memory access, and fusion so the algorithm is truly tractable on hardware.
+
+## Method
+
+### Step 1: Formalize I/O Spec
+Define the input domain, output domain, and constraints. The input specification states data types (integer/floating-point/string/graph), scale range n∈[1,10^6], and validity conditions (preconditions); the output specification states the return type, precision, and boundary handling; constraints cover time/space limits and correctness guarantees (postconditions). Test: if you cannot write down the precondition/postcondition predicates, the specification is not yet formal enough.
+
+### Step 2: Decompose into Sub-problems
+Break the large problem into independently solvable pieces with clear boundaries and well-defined interfaces. Decomposition strategies: by data (processing different subsets), by function (completing different subtasks), by level (coarse-to-fine refinement). Good decomposition makes each sub-problem independently verifiable and the whole recursively verifiable; dependencies between sub-problems must be explicitly annotated to avoid implicit coupling.
+
+### Step 3: Design the Procedure
+Choose an algorithmic paradigm — this is the core decision; choosing wrong wastes all subsequent effort:
+
+- **Divide-and-Conquer**: Partition, solve sub-parts, merge. Sub-problems are independent; merge cost is lower than solving the whole. Classics: merge sort, quicksort, Strassen matrix multiplication. Recurrence T(n)=aT(n/b)+f(n), solved by the Master Theorem.
+- **Dynamic Programming (DP)**: Overlapping sub-problems, memoization to avoid repetition. Optimal substructure holds. Classics: shortest paths, knapsack, sequence alignment.
+- **Greedy**: Locally optimal at each step, hoping for global optimality. Greedy-choice property holds. Classics: Dijkstra, Huffman, MST.
+- **Backtracking**: Systematic search, pruning and retreating upon hitting dead ends. Search space has structure. Classics: N-queens, exact TSP, CSP.
+- **Randomized**: Probabilistic shortcuts, trading randomness for efficiency. Deterministic cost is too high. Classics: randomized quicksort, Monte Carlo, Las Vegas.
+
+Selection principle: independent → divide-and-conquer; overlapping → DP; greedy property → greedy; structured search → backtracking; deterministic cost too high → randomized. Practical problems often mix multiple paradigms.
+
+### Step 4: Analyze Complexity
+Time O(f(n)), space O(g(n)), distinguishing worst case from average case. Identify basic operation counts, solve recurrences (Master Theorem), and attend to how input distributions affect average-case complexity; beyond O (upper bound), attend to Ω (lower bound) and Θ (tight bound). Complexity analysis is an ongoing assessment during design, not post-hoc verification. Practical significance: for n=10^6, O(n) ≈ 10^6 steps (seconds), O(n²) ≈ 10^12 steps (infeasible), O(2^n) far exceeds the age of the universe.
+
+### Step 5: Prove Correctness
+Use loop invariants, structural induction, termination proofs, and pre/postconditions. An unverified algorithm is a guess. Loop invariant: initialization (holds before the loop), maintenance (preserved by each iteration), termination (invariant plus termination condition yields the postcondition); structural induction: assume correctness of sub-calls and prove the current call; termination: construct a decreasing measure and prove it strictly decreases; Hoare logic: {P} S {Q}.
+
+### Step 6: Check Tractability
+Is the problem in P? NP-hard? Undecidable? P → pursue the optimal exact algorithm; NP-hard → approximation/heuristics with explicit error bounds or probabilistic guarantees; undecidable → find a decidable restricted version. Common NP-hard problems: TSP, graph coloring, subset sum, SAT; common undecidable problems: the halting problem, Hilbert's tenth problem.
+
+### Step 7: Optimize and Improve
+Reduce constant factors, leverage data structures, parallelize — based on bottleneck analysis, not blind tuning. Optimization levels: (1) Algorithm level — switch to a superior paradigm (O(n²) → O(n log n) yields the largest gain); (2) Data structure level — switch to better storage/query structures; (3) Implementation level — caching, parallelism, SIMD, operator fusion; (4) Problem level — reformulate for easier solving (may yield qualitative leaps). Priority: algorithm level > data structure level > implementation level; problem level may enable leaps. Re-verify correctness after every optimization.
+
+## Common Errors
+
+| Error | Critique | Correct Approach |
+|-------|----------|-----------------|
+| Assuming exponential algorithms are acceptable | NP-hard problems require heuristics for large n, not exact solutions; 2^50 steps at 1ns each takes 35 years | Use approximation/heuristics for large n with explicit error bounds |
+| Failing to prove termination | Infinite loops are a real risk; hanging is far more dangerous than slow results | Prove termination via a decreasing measure; construct a decreasing function on a well-ordered set |
+| Confusing worst case with average case | Quicksort is worst-case O(n²) but average O(n log n); the worst case can occur in practice | Clearly state the analysis scenario and note assumptions |
+| Confusing existence with constructibility | A solution may exist but be uncomputable; existence ≠ constructibility | Distinguish existence proofs from algorithmic constructions |
+| Underestimating constant factors | O(n log n) with a huge constant may be slower than O(n²) with a small constant | Benchmark empirically; attend to constants and cache effects |
+| Ignoring space complexity | A time-efficient algorithm may exhaust memory; DFS needs O(n) but BFS needs O(2^n) | Analyze both time and space |
+| Premature optimization | Optimizing before proving correctness; the direction may be entirely wrong | Prove correctness first → analyze complexity → then optimize |
+| Ignoring input distribution | Average-case complexity depends on distributional assumptions; random input ≠ real input | State distributional assumptions explicitly; analyze real-world scenarios |
+| Serial / unfusable algorithms on GPU | Unpredictable branching, serial dependency chains, repeated memory reads/writes — "beautiful but intractable" | Adapt to parallel / fusible / sub-quadratic form; pass the GPU eight-dimension gate |
+
+## Operating Procedure
+
+When this skill is triggered, the output must include:
+
+1. **Input specification**: `[Input]: [description]` — e.g., `[Input]: unsorted integer array A[1..n], n∈[1,10^6]`
+2. **Output specification**: `[Output]: [description]` — e.g., `[Output]: A sorted in ascending order`
+3. **Algorithm paradigm**: `[Paradigm]: [divide-and-conquer/DP/greedy/backtracking/randomized] because [reason]`
+4. **Complexity**: `[Time]: O([f(n)]) [Space]: O([g(n)]) [Scenario]: [worst/average]`
+5. **Correctness**: `[Loop invariant/induction strategy]: [content] ✅ proved / ❌ not proved`
+6. **Tractability**: `[Class]: [P/NP-hard/undecidable] [Response]: [exact/approximate/heuristic/reformulate]`
+7. **Improvement suggestions**: `[Optimization direction]: [specific suggestions]`
+8. **[GPU feasibility]** (if used for algorithm/operator design) — complexity order / parallelism / memory access / fusion assessment, annotate as friendly / retrofittable / anti-pattern + adaptation suggestions
+
+**The output must not present analysis alone without a conclusion.**
+
+## Relations to Other Skills
+
+- **Optimization thinking**: Gradient descent, branch-and-bound, and other optimization algorithms are instances of algorithmic thinking — optimization focuses on the optimal value, while algorithms focus on the steps and cost to reach it.
+- **Transformation thinking**: FFT is a paradigmatic application of algorithmic thinking to transformations — O(n²) → O(n log n); transformations map problems to easily solvable spaces, and algorithms solve them efficiently in the transformed space.
+- **Logical deduction**: Correctness proofs use deductive reasoning (loop invariants, induction) — an algorithm correctness proof is essentially a chain of deductive steps.
+- **Induction and analogy**: Divide-and-conquer uses structural analogy — sub-problems are isomorphic to the original problem — which is precisely the algorithmic embodiment of inductive thinking.
+- **Discrete / Combinatorial thinking**: Algorithms process discrete objects, and combinatorial counting underpins complexity analysis — combinatorial explosion is the core obstacle algorithmic thinking must overcome.
+- **Modern mathematics activation**: `../../references/books/matrix-analysis.md` (GEMM / low-rank decomposition for order reduction), `../../references/books/optimization-ml.md` (GPU feasibility of first-order / second-order methods), `../../references/books/abstract-algebra.md` (parallel algorithms over semirings / finite fields).

package/skills/algorithmic-thinking/SKILL.md

@@ -5,6 +5,8 @@ description: |
   English: Trigger when a problem needs finite-step solving, algorithm design, complexity analysis (time/space), tractability & parallelism assessment (P/NP-hard/undecidable); or termination/correctness proofs; or designing executable algorithms/operators for GPU (assessing complexity order, parallelism, memory access & fusion).
 ---
 
+> **语言路由**：若用户消息为英文，请读取并遵循同目录下的 `SKILL.en.md`，按其操作规程以英文输出；中文消息则继续使用本文件。
+
 # 🖥️ 算法与计算思想 / Algorithmic Thinking
 
 > "算法是思想的自动化——将洞察转化为可重复执行的精确步骤。"