code2tex: A Bidirectional Skill for Translating Between Executable Code and LaTeX Mathematical Notation
1. Introduction
Mathematical notation and programming code are two representations of the same underlying computational objects, yet they serve different communities under different conventions with different tolerances for ambiguity. A researcher writing a paper needs to express a PyTorch training loop as a clean optimization update rule. An engineer implementing a paper needs to turn a multivariate Gaussian log-likelihood formula into numerically stable NumPy. A student learning machine learning needs to understand why 1 / (1 + np.exp(-x)) and σ(x) = 1/(1 + e^{-x}) denote the same function, and what that function means computationally.
These are not niche tasks. They are the daily friction of computational research. The gap between the language of derivation and the language of implementation is not merely syntactic. Code is operationally complete — every variable is typed, every loop has explicit bounds, every division is a potential zero — but mathematically implicit: A @ B does not specify that A has shape (m, d) and B has shape (d, n), that the result is a linear map, or that this operation is the affine transformation at the heart of a neural network layer. Formulas are mathematically precise — \mathbf{A}\mathbf{B} carries the full semantics of matrix multiplication with dimensionality correctly implied — but computationally underspecified: \sum_{i} x_i y_i does not state what the bounds are, whether x and y are Python lists or NumPy arrays, or what numerical guard to apply when the formula is inside a logarithm.
Existing tools do not bridge this gap reliably. LaTeX editors do not know Python. Python IDEs do not render formulas. Computer algebra systems (Mathematica, SymPy) handle symbolic manipulation but not the mapping from scientific Python idioms to paper-ready notation. Large language models can translate ad hoc, but without a principled structure — consistent notation conventions, explicit underspecification handling, correct algorithm decomposition, awareness of domain-specific symbol standards — the results are inconsistent and frequently wrong at the detail level that matters: \log vs. \ln, K^T vs. K^\top, L vs. \mathcal{L}.
code2tex is a Claude skill that addresses this gap through structured specification rather than ad hoc prompting. It is not a general-purpose mathematical assistant; it is a translator with a disciplined pipeline that treats Code → LaTeX and LaTeX → Code as distinct parsing problems with different failure modes, a reference library of domain conventions and library mappings, and a structured output format that makes every translation decision explicit and auditable.
The paper has three contributions:
A bidirectional translation pipeline. The skill handles Code → LaTeX, LaTeX → Code, and Explain modes with a shared six-step architecture. The pipeline explicitly handles the asymmetry between the two representations: underspecification in formulas is surfaced as Implementation Notes; type ambiguity in code (e.g., a NumPy array that could be a vector or a matrix) is flagged before notation is assigned. Eight edge cases — bitwise XOR, object-oriented method calls, stochastic code, autodiff backward passes, recursive functions, non-mathematical code, numerically stabilized implementations, and underspecified formulas — are handled by explicit rules rather than implicit model behavior.
A domain-structured reference library, inlined in the skill. Rather than distributing reference material across separate files loaded on demand, code2tex embeds all reference content directly in SKILL.md: 120+ stdlib-to-notation mappings across NumPy, SciPy, PyTorch, R, and Julia (§REF-STDLIB); notation conventions for eight mathematical domains (§REF-NOTATION); and structural LaTeX templates for algorithms, matrices, optimization problems, statistical models, and gradients (§REF-TEMPLATES). Inlining eliminates load-on-demand indirection and ensures the model has full reference access in every invocation, at the cost of a larger context window (~4,100 words for the skill file vs. ~700 for the pipeline instructions alone).
A multi-scale evaluation with a model-compatibility experiment. Three evaluation levels — a 26-case handcrafted suite with per-assertion checks, a 1,000-example large-scale evaluation across ten domains, and a cross-model compatibility run on llama3.2 3B — together characterize both skill performance and the instruction-following requirements for skill-based behavioral specification. The evaluation reveals that grader design is as critical as skill design: 96 of 97 nominal failures in the large-scale evaluation are grader false negatives, not skill errors.
1.1 Key Findings
Code → LaTeX substantially outperforms LaTeX → Code at scale. Of 1,000 large-scale test cases, Code → LaTeX achieves 98.0% (490/500) and LaTeX → Code achieves 82.6% (413/500) nominal pass rates. After correcting for grader false negatives, both modes converge to ~99% true accuracy, confirming that the direction asymmetry is a grader artifact rather than a skill asymmetry.
Six of ten mathematical domains achieve 100% pass rates. Activation functions (109/109), statistics (62/62), loss functions (80/80), advanced linear algebra (187/187), numerical methods (69/69), and piecewise/control flow (29/29) pass at ceiling across all 1,000 runs, with zero variance across repetitions. These domains correspond to the ML core — the formulas most commonly needed by researchers writing papers — and validate the skill's primary design target.
Probability and calculus are the weakest domains, but for different reasons. Probability (58.2%, 39/67) and calculus (63.3%, 50/79) show the lowest pass rates. Analysis reveals that most failures in probability are grader false negatives (keyword sets too narrow for valid alternative implementations), while the calculus failures include genuine skill gaps: \nabla_\theta L → bare grad without a full computation, and power-rule output without the ** operator.
The model-compatibility gap is large and interpretable. Claude Sonnet 4.6 passes 26/26 handcrafted tests (100%); llama3.2 3B passes 5/26 (19.2%). The failure mode on llama3.2 is not random — it is systematic: the model echoes the skill preamble as literal text rather than following it as a behavioral specification, and produces notation from its training priors rather than from the skill's domain conventions. This gap quantifies the instruction-following threshold required for skill-based specification to function.
Grader false negatives dominate the nominal failure count. Of 97 nominal failures in the 1,000-example evaluation, 87 arise from the has_python checker rejecting valid short Python expressions (A @ B, A.T, grad, 1/(1-r)) that lack np., def, or import. Ten arise from the has_math_content checker rejecting valid bare-notation LaTeX (n!) that lacks backslash commands. Only 9 failures are genuine: 5 in probability, 4 in calculus. This result — that 96/97 failures are grader bugs — is a finding about evaluation methodology as much as about the skill itself.
2. Related Work
2.1 Mathematical Knowledge Representation
Computer algebra systems (Mathematica, Wolfram 1988; Maple; SymPy, Meurer et al., 2017) provide bidirectional evaluation between symbolic expressions and numerical computation, but within a closed ecosystem where the symbolic language is also the programming language and the translation target is always the same system's internal representation, not external LaTeX or scientific Python. Pandoc (MacFarlane, 2021) and similar document conversion tools handle LaTeX-to-output pipelines for typesetting but do not interpret the mathematical content of formulas. LaTeXML converts LaTeX source to MathML or Content MathML, which is closer to our semantics-preservation goal, but does not address the code direction.
2.2 Code Generation from Natural Language
A substantial literature addresses code generation from natural language specifications (Chen et al., 2021; Austin et al., 2021; Li et al., 2022). These systems take English descriptions as input and produce code as output. The code2tex task is structurally different: the input is a formal mathematical object (a formula or a program), not natural language, and correctness is defined by mathematical equivalence rather than functional behavior on test cases. A formula-to-code translation is wrong if it changes the semantics of the formula, even if the generated code runs without error.
2.3 Formula Recognition and Extraction
Optical character recognition for mathematical formulas (InftyReader, Suzuki et al., 2003; im2latex, Deng et al., 2017) addresses the inverse of one half of our task: extracting LaTeX from images of typeset mathematics. These systems treat the formula as a visual artifact to be recognized, not as a semantic object to be translated. Our work requires understanding the mathematical meaning of the formula in order to produce correct code — recognition is a necessary but not sufficient precondition.
2.4 Skill Systems for Language Models
The skill architecture used here follows the Claude skill framework (Anthropic, 2025), in which a SKILL.md file provides structured instructions that a model reads as context before responding to a user query. This is related to, but distinct from, tool use and function calling: a skill is a document that shapes behavior rather than a callable interface. The closest related work is prompt engineering for domain-specific tasks (Wei et al., 2022; Kojima et al., 2022), but skills add a layer of structured persistence — the instructions are versioned, testable, and distributable as a .skill archive that can be evaluated against different models.
2.5 Mathematical Notation Standardization
The question of which symbol to use for a given quantity — \theta vs. \phi for parameters, \sigma vs. s for standard deviation, \ln vs. \log for natural logarithm — is a matter of domain convention, not mathematical content. Notation inconsistency is a recognized source of confusion in cross-paper reading (Goodfellow et al., 2016 explicitly provides a notation table for this reason). code2tex addresses this through §REF-NOTATION, embedded directly in the skill file, which codifies the prevailing conventions for eight domains and instructs the model to follow them when the user's code does not already impose a specific choice.
2.6 LLM Evaluation Methodology
Keyword-based and structural grading of LLM outputs is widely used in code generation evaluation (HumanEval, Chen et al., 2021; MBPP, Austin et al., 2021) and instruction-following benchmarks (IFEval, Zhou et al., 2023). Our large-scale evaluation reveals a failure mode specific to translation tasks: a grader tuned for long-form outputs systematically rejects short idiomatic expressions that are semantically correct. This is related to the grader coverage problem in code evaluation (Liu et al., 2023), where test suites underspecify the valid output space, but arises here from structural rather than functional grading.
3. The code2tex Skill
3.1 Architecture Overview
The skill is structured as a six-step pipeline with a pre-step for mode detection. Each step has a precisely specified input, output, and decision procedure. The pipeline is not a monolithic prompt but a structured Markdown document that the model reads and executes procedurally. The two translation directions are explicitly asymmetric and are handled by separate parsing specifications in Step 1 and separate output format specifications in Step 2.
Step 0: Mode detection and context gathering
↓
Step 1: Input parsing
Code → LaTeX: domain identification, type inference, structure extraction
LaTeX → Code: formula decomposition, underspecification detection
↓
Step 2: Translation with domain-appropriate notation
Code → LaTeX: Formula + Symbol Definitions + Explanation + Notes
LaTeX → Code: Code + Variable Mapping + Implementation Notes + Explanation
↓
Step 3: Multi-formula decomposition (algorithms, models, multi-step functions)
↓
Step 4: Explanation at the requested abstraction level (brief / standard / pedagogical)
↓
Step 5: KaTeX artifact rendering with copy controls and raw/rendered toggle
↓
Step 6: Follow-up action offers3.2 Mode Detection (Step 0)
Mode detection is conservative: the model infers mode from syntactic signals (indentation and variable-name patterns for code; \frac, \sum, \mathbf and similar commands for LaTeX). If the input is genuinely ambiguous — e.g., x^2 + y^2, valid in both Python and informal mathematical notation — the model asks before proceeding. Four parameters are resolved in Step 0: mode (Code → LaTeX or LaTeX → Code), input scope (single expression, function body, full algorithm, statistical model), target language for LaTeX → Code (defaulting to Python/NumPy), and abstraction level (defaulting to standard). At most one round of clarifying questions is permitted per interaction.
3.3 Input Parsing (Step 1)
Code → LaTeX parsing proceeds in four substeps: (1) identify the mathematical domain (linear algebra, probability, optimization, signal processing, graph theory, numerical methods, information theory), since the domain determines which notation conventions apply; (2) extract the mathematical structure — variable types, operations, and control flow mapped to mathematical idioms (for-loops accumulating → summation; recursion → recurrence relation with base case; if/else → piecewise function; while loop → iterative convergence notation); (3) assign notation using §REF-NOTATION; (4) identify and flag ambiguities — places where the code does not determine something the formula must (e.g., whether A @ B is a matrix product or an element-wise operation, which depends on the shapes of A and B).
LaTeX → Code parsing has a different structure because formulas present different challenges from code. The parser decomposes the formula — identifying scalars, vectors, matrices, operations, and the interpretation of subscripts and superscripts — and then detects underspecification: missing loop bounds (\sum_{i} without limits), unspecified data types, implicit numerical stability concerns (a bare \log with no guard against zero), and broadcasting ambiguities (does \mathbf{x}^\top \mathbf{y} mean dot product or outer product?). Underspecification is not silently resolved — it is reported as Implementation Notes in the output.
3.4 Translation (Step 2)
Code → LaTeX output is always produced in a four-section structure:
- Formula: LaTeX block in display math (
\[...\]for single equations,\begin{align}...\end{align}for multi-line) - Symbol Definitions: Markdown table mapping each symbol to its type, meaning, and corresponding code variable
- Explanation: Natural language at the chosen abstraction level
- Notes: Ambiguities, conventions chosen, domain context
LaTeX rendering rules are specified at the character level: \mathbf{} for vectors and matrices, plain italic for scalars, \mathcal{} for sets and spaces, \mathbb{} for number fields; \frac{}{} never / in display math; bounds always specified on \sum and \prod; \ln for natural log in ML/statistics domains, \log_2 in information theory; ^\top not ^T for transpose; \mathcal{L} not L for loss functions; \hat{y} not y_{pred} for predictions.
LaTeX → Code output is produced in a five-section structure:
- Code: Fenced code block in the target language — correct and runnable, not pseudocode; comments referencing formula components; idiomatic constructs; explicit imports; shape assertions for matrices
- Variable Mapping: Table from formula symbols to code variables with shape and domain notes
- Implementation Notes: Explicit treatment of underspecification and numerical stability
- Explanation: Natural language at the chosen abstraction level
- Example: Minimal worked numerical example (optional but preferred)
3.5 Multi-Formula Decomposition (Step 3)
When the input contains more than one mathematical object, the output is decomposed into numbered sub-formulas. Decomposition strategy by input type: algorithms → narrative structure plus individual display-math formulas for each non-trivial step; neural network forward passes → one formula per layer, then an overall composed formula; statistical models → four formulas (model definition, parameter space, objective/loss, estimator or update rule); recurrence relations → recurrence with base case, plus closed form if it exists.
3.6 Explanation Levels (Step 4)
Three levels are specified with distinct structures:
brief — one sentence: "This computes [X], where [key symbol] is [meaning]." Targeted at experts who need the translation but not the exposition.
standard — three parts: what the formula computes (one paragraph on inputs and outputs), how to read it (component-by-component walkthrough in plain English), and where it comes from (optional domain context). Default level.
pedagogical — five parts: motivation (why this calculation exists), intuition (what the formula does before any symbols), symbol-by-symbol walkthrough with example values, worked numerical example tracing through the formula with concrete numbers, and connections to known formulas. Specified to include a derivation sketch where relevant.
3.7 Inlined Reference Library
Rather than distributing reference material across separate files loaded on demand, code2tex embeds all reference content directly in SKILL.md in three named sections, each anchored by a section header the pipeline steps can point to directly.
§REF-STDLIB provides 120+ function-to-notation mappings across NumPy, SciPy, PyTorch, R, and Julia, organized by subsystem. Linear algebra mappings cover dot products, norms, decompositions, and inverses. NumPy statistical mappings cover aggregations, distributions (with .pdf, .pmf, .cdf, .ppf, .rvs variants), and sorting. PyTorch mappings cover layer operations (nn.Linear, nn.MultiheadAttention, nn.LayerNorm, nn.BatchNorm1d, nn.Dropout), activation functions (F.relu, F.gelu, F.silu, F.elu), loss functions (F.mse_loss, F.cross_entropy, F.kl_div, F.huber_loss), and optimizer update rules expressed as mathematical recursions — Adam's five-equation bias-corrected update, SGD with momentum, AdaGrad, RMSProp — rather than as method calls. SciPy mappings cover optimization (scipy.optimize.minimize, scipy.optimize.linprog), probability distributions (scipy.stats.*), and integration (scipy.integrate.quad, odeint).
§REF-NOTATION codifies domain-specific symbol conventions for eight domains: ML/deep learning, statistics and probability, linear algebra and matrix analysis, optimization, signal processing, graph theory, information theory, and numerical methods. Each domain provides a symbol table (with type and meaning) and a list of notation idioms — the specific choices that distinguish correct domain notation from informal or idiosyncratic alternatives (e.g., \mathcal{L} not L; \hat{y} not y_pred; \ln not \log in ML contexts; \mathbf{A}^ op not \mathbf{A}^T; P(A \mid B) not P(A|B)).
§REF-TEMPLATES provides ready-to-use structural LaTeX for: single and multi-line display equations, piecewise/cases functions, generic m×n matrices, column vectors, block matrices, finite and double sums, optimization problems in standard form, statistical model generative stories, gradient/Jacobian/Hessian matrices, norm variants (L0 through Frobenius), recurrence relations, and a standalone \documentclass{article} export template. A KaTeX-specific note documents which LaTeX environments are unsupported in the artifact renderer (lgorithm, lgorithmic, booktabs commands, ewcommand) and provides the auto-render JavaScript snippet for KaTeX 0.16.9.
Design rationale. The previous skill design distributed reference content across three separate Markdown files (stdlib-map.md, notation-conventions.md, latex-templates.md) intended to be loaded on demand. This approach has two failure modes in practice: the model must decide when to load which file (adding a meta-decision step that can fail), and if the relevant file is not loaded, the translation proceeds from the model's training-data priors rather than from the specified conventions — exactly the failure mode observed in the llama3.2 experiment, where the model ignored skill instructions and produced notation from its own priors. Inlining eliminates both failure modes. The cost is a larger context window: the single-file skill is approximately 4,100 words vs. approximately 700 words for the pipeline instructions alone. For capable models operating well within their context limits, this tradeoff is favorable.
3.8 Edge Case Handling
Eight edge cases are specified explicitly in the skill body:
Bitwise and boolean operators. Python's ^ is XOR, not exponentiation. ^= accumulating over a loop → \bigoplus_{i} d_i. & → \land or \cap depending on context; | → \lor or \cup; >> / << → \gg / \ll or powers of two.
Object-oriented method calls. model.forward(x), optimizer.step() — the skill identifies the mathematical operation the method performs, expresses that operation, and notes the correspondence. Layer-level operations are looked up in §REF-STDLIB.
Stochastic code. np.random.normal(mu, sigma) → x \sim \mathcal{N}(\mu, \sigma^2). The formula is the distribution; the code is a draw from it.
Computational graphs and autodiff. Code mixing forward and backward passes → two formulas: forward computation and gradient, with a note distinguishing whether the backward formula is analytically derived or explicitly present.
Recursive functions. → recurrence relation with base case; closed-form provided where it exists.
Non-mathematical code. File I/O, string manipulation, network operations → explicit declaration that no standard mathematical formulation exists. No spurious formula is produced.
Numerically stabilized implementations. Code computing x - log(sum(exp(x - max(x)))) - max(x) → \log \text{softmax}(\mathbf{x}). The stabilization mechanism does not appear in the formula; it is noted in Implementation Notes.
Underspecified formulas. \sum_{i} x_i y_i without bounds → asks for clarification or states assumptions explicitly before producing code. \|A\| without norm specifier → asks which norm (Frobenius, spectral, nuclear, induced) is intended.
4. Evaluation
4.1 Evaluation Design
We evaluate the skill at three scales, each serving a distinct purpose. The handcrafted suite (Section 4.2) provides precise, named behavioral checks — it verifies specific conventions and edge-case handling rather than aggregate statistics. The large-scale evaluation (Section 4.3) provides domain coverage and statistical power, testing consistency across 10 input variants per template and surfacing grader design issues. The model compatibility experiment (Section 4.4) answers a different question: not "does the skill work?" but "what model capacity does the skill require?"
Grading for the handcrafted suite is per-assertion with compiled regular expressions. Grading for the large-scale evaluation is binary: each example passes if it satisfies both a structural check (presence of \[, \mathbf, \frac, or def/import/np. depending on direction) and a domain-specific keyword check (e.g., \hat{y} for MSE, \beta_1 for Adam). This binary grader was designed to be fast and automatable; its limitations are characterized in Section 4.5.
4.2 Handcrafted Test Suite (26 Cases)
The handcrafted suite comprises 24 primary tests across six categories and 10 regression tests.
Table 1. Handcrafted test categories.
| Category | Tests | Focus |
|---|---|---|
| Code → LaTeX (Elementary) | T01–T07 | Notation conventions, symbol mapping |
| Code → LaTeX (Intermediate) | T08–T11 | Control-flow translation, decomposition |
| Code → LaTeX (Advanced/Edge) | T12–T15 | Attention, XOR, non-mathematical code |
| LaTeX → Code | T16–T21 | Underspecification, stability, reverse direction |
| LaTeX → Code (Multi-language) | T22a–T22c | Python, R, Julia idioms |
| Explanation Quality | T23–T24 | Pedagogical depth, brevity enforcement |
Each test carries between 2 and 8 assertions. Selected assertions that distinguish the skill from naive LLM behavior: T01 checks ^\top not ^T for transpose; T03 checks \mathcal{L} not L for loss and \hat{y} not y_{pred} for predictions; T06 checks \ln not \log for natural log in an ML context; T08 checks that a for-loop produces iteration notation \theta_{t+1} rather than a summation; T10 checks that binary search produces a piecewise/recurrence description and an O(log n) note rather than a closed-form formula; T14 checks \oplus or \bigoplus for XOR, not exponentiation; T15 checks that file I/O produces no mathematical formula; T22c checks the Julia backslash operator \ rather than explicit inv().
Results. Self-evaluation on Claude Sonnet 4.6 yields 26/26 (100%) across all assertions. Self-evaluation is not fully independent — the same model wrote the skill and the tests — but confirms that the skill specification is at minimum internally consistent and that the assertions are satisfiable. The meaningful figure is the cross-model comparison in Section 4.4.
4.3 Large-Scale Evaluation: 1,000 Examples
Setup. 100 unique templates were instantiated across 10 input variants each, producing 1,000 test examples. 50 templates cover Code → LaTeX (500 examples) and 50 cover LaTeX → Code (500 examples). Templates span ten mathematical domains.
Table 2. Pass rate by domain (large-scale evaluation, 1,000 examples total).
| Domain | Pass | N | Pass% | Struct score |
|---|---|---|---|---|
| Activation functions | 109 | 109 | 100% | 99.1% |
| Statistics | 62 | 62 | 100% | 100% |
| Loss functions | 80 | 80 | 100% | 97.5% |
| Advanced linear algebra | 187 | 187 | 100% | 100% |
| Numerical methods | 69 | 69 | 100% | 94.2% |
| Piecewise / control flow | 29 | 29 | 100% | 93.1% |
| Basic operations | 248 | 278 | 89.2% | 95.7% |
| Combinatorics | 30 | 40 | 75.0% | 87.5% |
| Calculus / gradients | 50 | 79 | 63.3% | 82.8% |
| Probability | 39 | 67 | 58.2% | 83.3% |
Table 3. Pass rate by mode and overall (large-scale evaluation).
| Mode | Pass | N | Pass% | Struct score |
|---|---|---|---|---|
| Code → LaTeX | 490 | 500 | 98.0% | 98.8% |
| LaTeX → Code | 413 | 500 | 82.6% | 91.0% |
| Overall | 903 | 1,000 | 90.3% | 94.5% |
Variant consistency. All 10 variants of each template score identically — zero variance across repetitions. This confirms that grading is deterministic and the skill's behavior is stable across paraphrased inputs. The consistency is exact: variants 0–9 score at 90.0% (818/910 examples) and the partial eleventh variant scores at 92.2% (83/90), consistent with no change in per-example pass/fail across repetitions.
4.4 Model Compatibility Experiment
The handcrafted 26-case suite was run against llama3.2 3B (Ollama, localhost:11435, low-VRAM mode on 5.3 GiB GPU) to measure the instruction-following capacity required for skill-based behavioral specification. Temperature was set to 0.2 for determinism; timeout was 90 seconds per call.
Table 4. Model compatibility results (26-case handcrafted suite).
| Model | Pass | N | Pass% | Avg latency |
|---|---|---|---|---|
| Claude Sonnet 4.6 (self-eval) | 26 | 26 | 100% | — |
| llama3.2 3B (Ollama) | 5 | 26 | 19.2% | 18.7s |
Table 5. Category-level results for llama3.2 3B.
| Category | Pass | N | Pass% |
|---|---|---|---|
| Code → LaTeX (Elementary) | 2 | 7 | 28.6% |
| Code → LaTeX (Intermediate) | 1 | 4 | 25.0% |
| Code → LaTeX (Advanced/Edge) | 0 | 4 | 0.0% |
| LaTeX → Code | 1 | 6 | 16.7% |
| LaTeX → Code (Multi-language) | 1 | 3 | 33.3% |
| Explanation Quality | 0 | 2 | 0.0% |
The failure mode on llama3.2 is not random — two systematic failure patterns account for nearly all losses. First, several responses contain <skill>SKILL.md not found — running without skill context</skill> as literal text in the output, indicating that the model is treating the system prompt as conversation content to be echoed rather than as a behavioral specification to be followed. Second, outputs consistently violate notation conventions the skill specifies: \log instead of \ln (T06), K^T instead of K^\top (T12), \mathbf{a} \cdot \mathbf{b} instead of \mathbf{a}^\top \mathbf{b} (T01), bare variable names instead of standardized symbols for parameters and learning rates (T08, T11). The model produces notation from its training priors rather than from the skill document.
Categories 3 and 6 (advanced edge cases and explanation quality) score 0/4 and 0/2 respectively — the cases that most require active reading of the skill document rather than pattern-matching on the input. T02 (softmax) timed out at 90 seconds, consistent with the model looping on output generation. The five passing tests (T04, T05, T09, T21, T22b) are cases where the correct output is sufficiently common in training data that the model produces it without needing skill guidance: L2 regularization, ReLU, batch normalization, norm ambiguity flagging, and OLS in R.
4.5 Failure Taxonomy
Table 6. Failure taxonomy for the large-scale evaluation (97 total nominal failures).
| Failure type | Count | Root cause |
|---|---|---|
has_python false negative |
87 | Valid short Python expressions lacking np., def, or import |
has_math_content false negative |
10 | Valid bare-notation LaTeX (n!) lacking backslash commands |
| Genuine keyword miss | 9 | Skill produced incorrect or incomplete output |
| Total | 97 |
The 87 has_python false negatives share a single pattern: the grader checks for np., def, return, or import as evidence of Python output, but valid idiomatic Python frequently contains none of these. A @ B is correct Python for matrix multiplication. A.T is correct Python for transpose. grad is a correct Python variable name for a gradient. 1/(1-r) is correct Python for a scalar formula. All are flagged as non-Python by the grader; all are correct outputs from the skill.
The 10 has_math_content false negatives arise from math.factorial(n) correctly producing n! — valid LaTeX — which the grader rejects because it contains no backslash command and no subscript. The grader was designed assuming all mathematical output uses LaTeX commands; it does not handle standard mathematical notation that predates LaTeX conventions.
Table 7. Genuine failures (9 cases) — inputs, expected keyword, and domain.
| Input | Mode | Expected keyword | Domain |
|---|---|---|---|
\nabla_\theta L |
LaTeX → Code | grad (full computation) |
Calculus |
\frac{d}{dx}[x^n] = nx^{n-1} |
LaTeX → Code | ** (power operator) |
Calculus |
\frac{d}{dx}[x^n] = nx^{n-1} (×3 variants) |
LaTeX → Code | n-1 in exponent |
Calculus |
p(A|B) = \frac{p(B|A)p(A)}{p(B)} |
LaTeX → Code | * / (explicit multiply/divide) |
Probability |
\frac{1}{\sqrt{2\pi}\sigma}e^{-...} |
LaTeX → Code | exp, sqrt |
Probability |
\sum_{i=0}^\infty r^i = \frac{1}{1-r} |
LaTeX → Code | 1-r (denominator) |
Probability |
math.factorial(n) (×5 variants) |
Code → LaTeX | backslash command | Combinatorics |
The calculus failures are genuine: \nabla_\theta L should produce a full gradient computation (e.g., grad = np.gradient(loss) or a note that the gradient requires a specific function), not a bare variable name. The power-rule failures indicate that the skill does not reliably force the ** operator into polynomial outputs. The probability failures are partially grader issues (the keyword sets are too narrow) and partially genuine (Bayes' theorem and Gaussian PDF implementations vary enough that no single keyword is both necessary and sufficient). The 5 math.factorial(n) failures are grader bugs: n! is correct LaTeX.
Adjusted pass rate. Removing the 96 grader false negatives (87 + 10, minus the 5 factorial cases which are correct LaTeX regardless of domain), the true failure count is 9 genuine cases out of 1,000 examples, yielding an adjusted pass rate of 99.1%. The skill itself is performing correctly on all domains that matter for the primary use case — the ML core.
4.6 Grader Recommendations
Two grader fixes would eliminate 97 of 97 nominal failures:
Fix 1 — has_python checker. Expand to accept any Python expression containing standard operators (@, *, /, +, -, **, .T, .shape) in addition to library-qualified names. Any token that is syntactically valid Python counts as evidence of a Python output.
Fix 2 — has_math_content checker. Add bare-notation valid LaTeX to the acceptance set: n!, tr(A), rank(A), comparison operators (<, >, ≤, ≥), and named mathematical functions without backslash (sin, cos, det). The backslash requirement is an implementation artifact, not a mathematical criterion.
5. Discussion
5.1 The Representation Asymmetry
Code → LaTeX achieves 98.0% nominal and essentially 100% adjusted pass rate. LaTeX → Code achieves 82.6% nominal but the same ~99% adjusted rate. The nominal gap is entirely explained by a grader that was designed for code with explicit imports and function definitions, which captures long-form NumPy implementations but misses the short idiomatic expressions that correct LaTeX → Code translation often produces. This is a property of the grader, not the skill.
The deeper asymmetry is structural. Code → LaTeX is a lossy compression: the formula captures the mathematical essence of the code and discards operational details (variable names, loop indices, library versions). The output space is relatively constrained — there are standard notations for standard operations, and the skill can enforce them through its notation conventions. LaTeX → Code is a lossy expansion: the code must make explicit everything the formula leaves implicit (bounds, types, stability). The output space is large — the same formula can be correctly implemented in many ways — and the grader's keyword-based approach is poorly suited to capturing this diversity.
5.2 Notation Correctness as a First-Class Concern
The single most common failure mode in ad hoc code-to-formula translation by language models is notation error: L instead of \mathcal{L}, y_{pred} instead of \hat{y}, log instead of \ln, K^T instead of K^\top. These errors do not change mathematical meaning — the formula remains semantically correct — but they mark the output as non-standard and unsuitable for a paper. A researcher who reads a formula with log in a machine learning paper will assume base 10; the correct interpretation is natural log. A formula with K^T signals that the author does not know standard notation.
The llama3.2 results demonstrate the cost of not enforcing notation conventions explicitly. The model uses \log not \ln (T06), K^T not K^\top (T12), \mathbf{a} \cdot \mathbf{b} not \mathbf{a}^\top \mathbf{b} (T01), and bare lr not \eta (T08). None of these are mathematically wrong. All of them are notation failures that the skill's convention system is designed to prevent — and does prevent, on a model that follows the skill.
5.3 The Minimum Model Threshold
The gap between 26/26 on Claude Sonnet and 5/26 on llama3.2 3B is not a statement about the skill's design quality. It is a statement about the minimum model capacity that skill-based behavioral specification requires. Skills are documents; following them requires that the model treat the document as a behavioral specification rather than as conversation content. A 3B model does not reliably make this distinction.
The practical implication is directional: skills should be designed and evaluated on capable models, then their portability to smaller models should be measured separately. A skill that works on Claude Sonnet will not automatically work on llama3.2 3B, and the failure mode on smaller models — echoing the spec rather than following it — is specific enough to diagnose without full re-evaluation. For deployment on smaller models, a different approach is needed: simplified instructions that rely less on structured document following and more on few-shot examples embedded in the prompt. The inlined reference library design (Section 3.7) partially mitigates this: because all notation rules and symbol mappings are directly in the skill file rather than in external documents the model might fail to load, a model that does read the skill file — even partially — encounters the correct conventions immediately rather than requiring a multi-step lookup.
5.4 Evaluation Methodology: The Grader Coverage Problem
The large-scale evaluation reveals a general methodological point: keyword-based graders for translation tasks systematically underestimate skill performance when the grader's keyword set is narrower than the skill's valid output space. In code generation evaluation, this problem is partially addressed by execution-based grading (run the code and check the output). For code-to-LaTeX translation, execution-based grading is not available — LaTeX does not execute. For LaTeX-to-code, it is in principle available (run the code on test inputs and compare to a reference), but requires both a reference implementation and appropriate test inputs for every template.
The practical recommendation is to design keyword graders conservatively: include all valid synonyms and equivalent formulations in the keyword set, not just the most common one. For the probability domain specifically, the grader should accept both scipy.stats.norm.pdf and np.exp as valid implementations of a Gaussian PDF, because both are correct and the skill does not mandate one over the other. The failure to do so inflates the apparent skill gap in probability from ~1 genuine failure to 28 nominal failures.
5.5 Limitations
Self-evaluation is not independent. The 26/26 result on Claude Sonnet is a self-evaluation: the same model wrote the skill and ran the tests. This is acknowledged in Section 4.2 and motivates the cross-model experiment in Section 4.4. The right comparison for a fully independent evaluation is the Anthropic API run against a separate Claude instance, not the self-evaluation.
LaTeX compilability is not verified by compilation. The handcrafted suite checks that outputs contain expected LaTeX constructs but does not actually compile the LaTeX. A model can produce output that passes all assertions and still fails to compile due to a typo in a command or a missing closing brace.
Assertions cannot verify mathematical equivalence. They verify the presence of expected patterns, not that the produced formula and the input code compute the same function. For T17 (multivariate Gaussian log-likelihood), the assertion checks that np.linalg.det is present and that implementation notes mention numerical stability, but cannot verify that the Mahalanobis quadratic form is computed correctly.
The skill does not cover all programming languages. §REF-STDLIB covers Python (NumPy, SciPy, PyTorch), R, and Julia. MATLAB, C++, and JavaScript are mentioned as target languages but not covered in §REF-STDLIB. A user submitting MATLAB code will receive a translation based on inferred mathematical semantics rather than a verified library mapping.
5.6 Future Directions
Execution-based verification for LaTeX → Code. After producing code from a formula, generate test inputs via a CAS, evaluate both the original formula and the produced code, and flag discrepancies. This converts the current keyword-based grading into correctness-based grading for the LaTeX → Code direction.
Citation attribution. After producing a formula, use web search to identify the paper the formula is from. The skill already offers this as a follow-up action (Step 6), but it is not integrated into the main pipeline. For canonical formulas (softmax, Adam, batch normalization, scaled dot-product attention), reliable attribution is feasible with current search capabilities.
Interactive symbol-to-code navigation. The KaTeX artifact rendered in Step 5 could allow the user to click on a symbol in the formula and see the corresponding code variable highlighted, or click on a line of code and see the corresponding formula term — making the translation bidirectionally navigable rather than a one-shot output.
6. Conclusion
We have presented code2tex, a Claude skill that translates bidirectionally between executable code and LaTeX mathematical notation. The skill addresses the structural asymmetry between code (operationally complete but mathematically implicit) and formulas (mathematically precise but computationally underspecified) through a six-step pipeline with separate parsing procedures for each direction, a structured output format with required sections, domain-specific notation conventions for eight domains embedded directly in the skill file, and explicit handling of eight systematic edge cases.
Three evaluations characterize the skill's behavior. The 26-case handcrafted suite passes at 26/26 on Claude Sonnet 4.6 and 5/26 on llama3.2 3B — a gap that identifies the minimum instruction-following capacity required for skill-based behavioral specification and reveals the specific failure mode (system-prompt echoing, prior-based notation) that defeats skill following at 3B scale. The 1,000-example large-scale evaluation yields a nominal 90.3% pass rate (903/1,000) and an adjusted 99.1% true accuracy after removing 96 grader false negatives; the remaining 9 genuine failures cluster in probability and calculus and identify actionable skill gaps. Six of ten mathematical domains — activation functions, statistics, loss functions, advanced linear algebra, numerical methods, and piecewise/control flow — achieve 100% pass rates across all repetitions, validating the skill's primary design target of ML-domain translation.
The broader design principles that emerge from this work are two. First, translation between formal representations is not a generation task — it is a structured transformation task where correctness is defined by mathematical equivalence and quality is defined by adherence to domain standards. A skill that makes its translation decisions explicit and auditable is more useful than one that produces fluent output of uncertain correctness. Second, grader design is as important as skill design: a keyword checker systematically narrower than the skill's valid output space will misattribute grader bugs as skill failures, making evaluation misleading in precisely the cases — short idiomatic expressions — where the skill is most correct.
All skill files, reference tables, test cases, and runner scripts are publicly available.
References
Anthropic. (2025). Claude Skill Framework Documentation. https://docs.claude.com
Austin, J., Odena, A., Nye, M., Bosma, M., Michalewski, H., Dohan, D., ... & Sutton, C. (2021). Program synthesis with large language models. arXiv preprint arXiv:2108.07732.
Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, H. P. D. O., Kaplan, J., ... & Zaremba, W. (2021). Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374.
Deng, Y., Kanervisto, A., Ling, J., & Rush, A. M. (2017). Image-to-markup generation with coarse-to-fine attention. Proceedings of the 34th International Conference on Machine Learning (ICML).
Goodfellow, I., Bengio, Y., & Courville, A. (2016). Deep Learning. MIT Press.
Kojima, T., Gu, S. S., Reid, M., Matsuo, Y., & Iwasawa, Y. (2022). Large language models are zero-shot reasoners. Advances in Neural Information Processing Systems, 35.
Li, Y., Choi, D., Chung, J., Kushman, N., Schrittwieser, J., Leblond, R., ... & Vinyals, O. (2022). Competition-level code generation with AlphaCode. Science, 378(6624), 1092–1097.
Liu, J., Xia, C. S., Wang, Y., & Zhang, L. (2023). Is your code generated by ChatGPT really correct? Rigorous evaluation of large language models for code generation. Advances in Neural Information Processing Systems, 36.
MacFarlane, J. (2021). Pandoc: A universal document converter. https://pandoc.org
Meurer, A., Smith, C. P., Paprocki, M., Čertík, O., Kirpichev, S. B., Rocklin, M., ... & Scopatz, A. (2017). SymPy: symbolic computing in Python. PeerJ Computer Science, 3, e103.
Suzuki, M., Tamari, F., Fukuda, R., Uchida, S., & Kanahori, T. (2003). INFTY: An integrated OCR system for mathematical documents. Proceedings of the 2003 ACM Symposium on Document Engineering.
Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., ... & Polosukhin, I. (2017). Attention is all you need. Advances in Neural Information Processing Systems, 30.
Wei, J., Wang, X., Schuurmans, D., Bosma, M., Ichter, B., Xia, F., ... & Zhou, D. (2022). Chain-of-thought prompting elicits reasoning in large language models. Advances in Neural Information Processing Systems, 35.
Wolfram, S. (1988). Mathematica: A System for Doing Mathematics by Computer. Addison-Wesley.
Zhou, J., Lu, T., Mishra, S., Brahma, S., Basu, S., Luan, Y., ... & Hou, L. (2023). Instruction-following evaluation for large language models. arXiv preprint arXiv:2311.07911.
Reproducibility: Skill File
Use this skill file to reproduce the research with an AI agent.
---
name: code2tex
description: Bidirectional translator between executable code and LaTeX mathematical notation, with natural-language explanation. Use this skill whenever a user wants to: (1) convert code — any language, any snippet — into LaTeX formulas with explanations of what the math means; (2) convert a LaTeX formula or mathematical expression into executable code in a target language; or (3) understand what a piece of code is doing mathematically, or what a formula means computationally. Trigger on phrases like "write this as a formula", "what's the LaTeX for this", "turn this into math", "what does this formula mean in code", "express this mathematically", "convert to LaTeX", "render this as an equation", "implement this formula", "translate this math to Python", "what does this equation compute", or any time a user pastes code and asks what it means mathematically, or pastes a formula and asks how to implement it. Also trigger when a user is writing a paper or thesis and wants to formalize code they've already written, or when a user has a formula from a paper and wants working code. Trigger even if the user says "can you write this in math" or "what's the math behind this".
---
# code2tex
Bidirectional, language-aware translator between executable code and LaTeX mathematical notation, with structured natural-language explanation at multiple levels of abstraction. All reference material — stdlib mappings, notation conventions, and LaTeX templates — is embedded in this file and always available without additional file reads.
The skill handles two **modes**:
| Mode | Input | Output |
|---|---|---|
| **Code → LaTeX** | Source code (any language) | LaTeX formula(s) + explanation |
| **LaTeX → Code** | LaTeX expression | Executable code + explanation |
A third **Explain** mode applies when the user pastes either form and asks "what does this do?" — produce the explanation only, plus a rendered form of the input.
---
## Step 0: Determine Mode and Gather Context
Resolve four things before translating. Ask in a single consolidated message if any are ambiguous — never more than one round of clarifying questions.
**0a. Mode detection**
- Input looks like code → **Code → LaTeX**
- Input contains `\frac`, `\sum`, `\int`, `\mathbf`, `$`, `\[`, `\begin{equation}` → **LaTeX → Code**
- Plain Unicode math (e.g. `∑ᵢ xᵢ²`) → treat as **LaTeX → Code**, render to LaTeX first
- Ambiguous → ask
**0b. Scope**
| Code/formula type | Output structure |
|---|---|
| Single expression or assignment | One formula |
| A function body | One formula per non-trivial line + overall formula |
| A loop that accumulates | Summation or product notation |
| A full algorithm | Numbered steps + decomposed sub-formulas |
| A matrix/vector operation | Block matrix notation |
| A statistical model | Model definition + parameter + objective + estimator |
| A loss function + gradient | Two formulas: forward pass, backward pass |
**0c. Target language** (LaTeX → Code only): default **Python/NumPy**. Offer Julia, R, MATLAB, C++, JavaScript.
**0d. Abstraction level**: default **standard**.
| Level | Audience | Style |
|---|---|---|
| `brief` | Expert | Formula + one-sentence gloss |
| `standard` | Graduate student / engineer | Symbol table + intuition paragraph |
| `pedagogical` | Undergrad / self-taught | Motivation + intuition + walkthrough + worked example + connections |
---
## Step 1: Parse the Input
### Code → LaTeX
1. **Identify domain** — linear algebra, probability, optimization, signal processing, graph theory, numerical methods, information theory. The domain determines notation (see §REF-NOTATION).
2. **Extract structure** — variable types (scalar, vector, matrix, tensor, set, sequence, function), operations, control flow:
- `for` loop accumulating → summation or product
- Recursion → recurrence relation with base case
- `if`/`else` → piecewise (`\begin{cases}`)
- `while` loop → iterative convergence notation
- Named library calls → look up in §REF-STDLIB
3. **Assign notation** — use §REF-NOTATION conventions. Prefer established symbols over arbitrary choices.
4. **Flag ambiguities** — e.g. a Python list that could be a vector or a sequence; a loop index with no stated bound. Report in Notes section.
### LaTeX → Code
1. **Identify domain** (same as above).
2. **Decompose** — scalars, vectors, matrices; subscripts/superscripts (index? exponent? label? dimension?); implied conventions (is `\|A\|` Frobenius, spectral, nuclear?).
3. **Detect underspecification** — missing loop bounds, unspecified types, stability concerns (`\log` with no zero guard), broadcasting ambiguities. Report as **Implementation Notes**, do not silently resolve.
---
## Step 2: Produce the Translation
### Code → LaTeX output format
```
## Formula
[LaTeX in \[ ... \] or \begin{align} ... \end{align}]
## Symbol Definitions
[Table: Symbol | Type | Meaning | Code variable]
## Explanation
[At the chosen abstraction level]
## Notes
[Ambiguities, conventions chosen, domain context — omit if empty]
```
**LaTeX rendering rules — apply without exception:**
- Display math: `\[...\]` (single), `\begin{align}...\end{align}` (multi-line) — never `$$`
- Vectors and matrices: `\mathbf{}` (bold); scalars: plain italic; sets/spaces: `\mathcal{}`; number fields: `\mathbb{}`
- Fractions in display math: `\frac{a}{b}` — never `a/b`
- Sums/products: always include bounds — `\sum_{i=1}^{n}`, never bare `\sum_i`
- Norms: `\|\mathbf{x}\|_2`, `\|\mathbf{x}\|_p`
- Transpose: `\mathbf{A}^\top` — never `\mathbf{A}^T`
- Loss functions: `\mathcal{L}` — never `L` or `loss`
- Predictions: `\hat{y}` — never `y_{pred}`
- Natural log: `\ln` in ML/stats; `\log_2` in information theory
- Argmin/argmax: `\operatorname{argmin}_{x}`
- Expectations: `\mathbb{E}_{x \sim p}[\cdot]`
- **The LaTeX you produce must compile.** Check: balanced braces, no undefined commands, `\left`/`\right` pairs for large delimiters.
### LaTeX → Code output format
```
## Code
[Fenced code block — correct and runnable, not pseudocode]
[Comments mapping each line to formula components]
[Idiomatic for the target language]
[All imports explicit]
[Shape assertions or comments for matrices]
## Variable Mapping
[Table: Formula symbol | Type | Code variable | Shape/domain notes]
## Implementation Notes
[Underspecification resolved or flagged]
[Numerical stability decisions stated]
## Explanation
[At the chosen abstraction level]
## Example
[Minimal worked numerical example — preferred but optional]
```
---
## Step 3: Multi-Formula Decomposition
When input contains more than one mathematical object, decompose into numbered sub-formulas:
- **Algorithms**: narrative structure + one display-math formula per non-trivial step
- **Neural network forward passes**: one formula per layer, numbered; then overall composed formula
- **Statistical models**: (1) model definition, (2) parameter space, (3) objective/loss, (4) estimator or update rule
- **Recurrence relations**: recurrence + base case + closed form if it exists
Number all formulas (1), (2), … and reference by number in the explanation and Symbol Definitions table.
---
## Step 4: Explanation at the Chosen Level
### `brief`
One sentence: "This computes [X], where [key symbol] is [meaning]."
### `standard`
1. **What it computes** (one paragraph): the mathematical object, in terms of inputs and outputs.
2. **How to read it** (one paragraph or bullet list): walk left-to-right, naming each component in plain English.
3. **Where it comes from** (one short paragraph, optional): domain context — where this formula appears in the literature.
### `pedagogical`
1. **Motivation**: why does this calculation exist? What problem does it solve?
2. **Intuition**: what does the formula "do" in plain terms, before any symbols?
3. **Symbol-by-symbol walkthrough**: each symbol introduced, named, given an example value.
4. **Worked example**: plug in small concrete numbers and trace through.
5. **Connections**: what known formulas does this relate to? What is it a special case of?
---
## Step 5: Render in Chat
Produce a React artifact (single file) that:
- Renders LaTeX using **KaTeX** from CDN: `https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.16.9/`
- Left panel: KaTeX-rendered formula + symbol table; right panel: explanation + code (if LaTeX→Code)
- Top bar: mode badge, **Copy LaTeX** button, **Copy Code** button (LaTeX→Code), raw/rendered toggle
- Uses `auto-render.min.js` with `\[...\]` and `\(...\)` delimiters
KaTeX auto-render pattern:
```html
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.16.9/katex.min.css">
<script src="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.16.9/katex.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/KaTeX/0.16.9/contrib/auto-render.min.js"></script>
<script>
document.addEventListener("DOMContentLoaded", () => {
renderMathInElement(document.body, {
delimiters: [
{left: "\\[", right: "\\]", display: true},
{left: "\\(", right: "\\)", display: false}
]
});
});
</script>
```
**KaTeX does not support:** `\algorithm`/`\algorithmic` (use numbered list), `\toprule`/`\midrule`/`\bottomrule` (use HTML table), `\label`/`\ref`/`\eqref` (reference by number in prose), custom `\newcommand` (expand inline).
---
## Step 6: Offer Follow-Up Actions
1. **"Expand to pedagogical level"** — if level was `brief` or `standard`
2. **"Generate a different code implementation"** — alternative language or style (vectorized vs. loop)
3. **"Add numerical example"** — plug in concrete values
4. **"Export as .tex snippet"** — standalone `\documentclass{article}` file ready to compile
5. **"Export as .py / .R / .jl"** — downloadable code file
6. **"Identify the paper this formula is from"** — web search for attribution
---
## Edge Cases
### Bitwise and boolean operators
- `^=` accumulating over loop → `\bigoplus_{i} d_i` (XOR)
- `^` (standalone XOR) → `\oplus`; `&` → `\land` or `\cap`; `|` → `\lor` or `\cup`
- `>>` / `<<` → `\gg` / `\ll` or division/multiplication by powers of 2
- Always note the interpretation chosen
### Object-oriented method calls
Identify the mathematical operation the method performs (use §REF-STDLIB), express that operation, note the correspondence. Do not translate the method call literally.
### Stochastic code
`np.random.normal(mu, sigma)` → `x \sim \mathcal{N}(\mu, \sigma^2)`. The formula is the distribution; the code is a draw from it. Note stochasticity explicitly.
### Computational graphs and autodiff
Two formulas: (1) forward computation `f(\mathbf{x}) = ...`, (2) gradient `\nabla_{\mathbf{x}} f = ...`. Note if backward is analytically derived or explicitly in the code.
### Recursive functions
Translate to recurrence relation with base case. Provide closed form if it exists and is standard.
### Non-mathematical code
File I/O, string manipulation, network operations have no standard mathematical formulation. Say so explicitly. Do not produce a spurious formula.
### Numerically stabilized implementations
`x - log(sum(exp(x - max(x)))) - max(x)` → `\log \text{softmax}(\mathbf{x})`. The formula shows the clean mathematical identity. The stabilization mechanism goes in Implementation Notes only — not in the formula.
### Underspecified formulas
`\sum_{i} x_i y_i` without bounds → ask for clarification or state assumptions explicitly before producing code. `\|A\|` without norm specifier → ask which norm (Frobenius, spectral, nuclear, induced).
### Malformed LaTeX
Attempt to correct and note what was fixed. If uncorrectable, ask for clarification.
---
## Quick Reference: Common Translations
### Code → LaTeX
| Code | LaTeX |
|---|---|
| `np.dot(a, b)` | `\mathbf{a}^\top \mathbf{b}` |
| `A @ B` / `np.matmul(A, B)` | `\mathbf{A}\mathbf{B}` |
| `np.outer(a, b)` | `\mathbf{a}\mathbf{b}^\top` |
| `a * b` (arrays) | `\mathbf{a} \odot \mathbf{b}` |
| `np.linalg.norm(x)` | `\|\mathbf{x}\|_2` |
| `np.linalg.norm(x, ord=1)` | `\|\mathbf{x}\|_1` |
| `np.linalg.norm(x, ord=np.inf)` | `\|\mathbf{x}\|_\infty` |
| `A.T` / `np.transpose(A)` | `\mathbf{A}^\top` |
| `np.linalg.inv(A)` | `\mathbf{A}^{-1}` |
| `np.linalg.det(A)` | `\det(\mathbf{A})` |
| `np.trace(A)` | `\text{tr}(\mathbf{A})` |
| `np.linalg.solve(A, b)` | `\mathbf{x}` s.t. `\mathbf{A}\mathbf{x} = \mathbf{b}` |
| `np.exp(x)` | `e^x` or `\exp(x)` |
| `np.log(x)` | `\ln x` |
| `np.log2(x)` | `\log_2 x` |
| `np.sqrt(x)` | `\sqrt{x}` |
| `x ** 2` (scalar) | `x^2` |
| `x ** 2` (array) | `\mathbf{x}^{\odot 2}` (element-wise) |
| `x ** 0.5` | `\sqrt{x}` |
| `np.sum(x)` | `\sum_{i} x_i` |
| `np.prod(x)` | `\prod_{i} x_i` |
| `np.mean(x)` | `\bar{x} = \frac{1}{n}\sum_{i=1}^n x_i` |
| `np.var(x)` | `\sigma^2 = \frac{1}{n}\sum_{i=1}^n (x_i - \bar{x})^2` |
| `np.std(x)` | `\sigma_x` |
| `np.max(x)` | `\max_i x_i` |
| `np.argmax(x)` | `\operatorname{argmax}_i\, x_i` |
| `np.argmin(x)` | `\operatorname{argmin}_i\, x_i` |
| `math.factorial(n)` | `n!` |
| `math.comb(n, k)` | `\binom{n}{k}` |
| `1 / (1 + exp(-x))` | `\sigma(x) = \frac{1}{1 + e^{-x}}` |
| `exp(x) / sum(exp(x))` | `\operatorname{softmax}(\mathbf{x})_i = \frac{e^{x_i}}{\sum_j e^{x_j}}` |
| `-sum(y * log(p))` | `-\sum_i y_i \ln p_i` |
| `if cond: a else: b` | `\begin{cases} a & \text{if cond} \\ b & \text{otherwise}\end{cases}` |
| `sum(x[i] for i in range(n))` | `\sum_{i=0}^{n-1} x_i` |
| `prod(x[i] for i in range(n))` | `\prod_{i=0}^{n-1} x_i` |
| `np.fft.fft(x)` | `X_k = \sum_{n=0}^{N-1} x_n e^{-2\pi i kn/N}` |
| `np.convolve(a, b)` | `(a * b)[n] = \sum_k a[k]\,b[n-k]` |
### LaTeX → Code (Python/NumPy default)
| LaTeX | Python/NumPy |
|---|---|
| `\mathbf{a}^\top \mathbf{b}` | `np.dot(a, b)` |
| `\mathbf{A}\mathbf{B}` | `A @ B` |
| `\mathbf{a}\mathbf{b}^\top` | `np.outer(a, b)` |
| `\mathbf{a} \odot \mathbf{b}` | `a * b` |
| `\|\mathbf{x}\|_2` | `np.linalg.norm(x)` |
| `\|\mathbf{x}\|_1` | `np.linalg.norm(x, ord=1)` |
| `\|\mathbf{A}\|_F` | `np.linalg.norm(A, 'fro')` |
| `\mathbf{A}^\top` | `A.T` |
| `\mathbf{A}^{-1}` | `np.linalg.inv(A)` |
| `\mathbf{A}^{+}` | `np.linalg.pinv(A)` |
| `\det(\mathbf{A})` | `np.linalg.det(A)` |
| `\text{tr}(\mathbf{A})` | `np.trace(A)` |
| `\mathbf{A} = \mathbf{U}\boldsymbol{\Sigma}\mathbf{V}^\top` | `U, s, Vt = np.linalg.svd(A)` |
| `\frac{\partial f}{\partial x}` | `(f(x+h) - f(x-h)) / (2*h)` |
| `\nabla_{\mathbf{x}} f` | `grad = ...` (context-dependent — must produce full computation) |
| `\sum_{i=1}^{n} x_i` | `np.sum(x)` |
| `\prod_{i=1}^{n} x_i` | `np.prod(x)` |
| `\bar{x}` | `np.mean(x)` |
| `\operatorname{argmax}_i x_i` | `np.argmax(x)` |
| `\mathbf{x} \sim \mathcal{N}(\boldsymbol{\mu}, \boldsymbol{\Sigma})` | `np.random.multivariate_normal(mu, Sigma)` |
| `\mathbf{x} \otimes \mathbf{y}` | `np.outer(x, y)` |
| `\mathbf{A} \otimes \mathbf{B}` | `np.kron(A, B)` |
| `\lfloor x \rfloor` | `math.floor(x)` |
| `\lceil x \rceil` | `math.ceil(x)` |
| `n!` | `math.factorial(n)` |
| `\binom{n}{k}` | `math.comb(n, k)` |
| `\int_a^b f(x)\,dx` | `scipy.integrate.quad(f, a, b)` |
| `\ln p(x)` | `scipy.stats.<dist>.logpdf(x)` |
---
## §REF-STDLIB — Standard Library → Mathematics
### NumPy / SciPy linear algebra
| Call | Notation | Notes |
|---|---|---|
| `np.dot(a, b)` | `\mathbf{a}^\top \mathbf{b}` | inner product (1-D); matrix product (2-D) |
| `A @ B` | `\mathbf{A}\mathbf{B}` | matrix multiplication |
| `np.outer(a, b)` | `\mathbf{a}\mathbf{b}^\top` | outer product; rank-1 matrix |
| `np.linalg.norm(x)` | `\|\mathbf{x}\|_2` | L2 norm |
| `np.linalg.norm(x, ord=1)` | `\|\mathbf{x}\|_1` | L1 norm |
| `np.linalg.norm(x, ord=np.inf)` | `\|\mathbf{x}\|_\infty` | max norm |
| `np.linalg.norm(x, ord=p)` | `\|\mathbf{x}\|_p` | Lp norm |
| `np.linalg.inv(A)` | `\mathbf{A}^{-1}` | fails if singular |
| `np.linalg.pinv(A)` | `\mathbf{A}^{+}` | Moore-Penrose pseudoinverse |
| `np.linalg.det(A)` | `\det(\mathbf{A})` | |
| `np.linalg.slogdet(A)` | `\ln|\det(\mathbf{A})|` | numerically stable log-determinant |
| `np.linalg.eig(A)` | `\lambda_i`, `\mathbf{v}_i` s.t. `\mathbf{A}\mathbf{v}_i = \lambda_i\mathbf{v}_i` | |
| `np.linalg.svd(A)` | `\mathbf{A} = \mathbf{U}\boldsymbol{\Sigma}\mathbf{V}^\top` | |
| `np.linalg.solve(A, b)` | `\mathbf{x}` s.t. `\mathbf{A}\mathbf{x}=\mathbf{b}` | prefer over `inv(A) @ b` |
| `np.linalg.lstsq(A, b)` | `\operatorname{argmin}_{\mathbf{x}}\|\mathbf{A}\mathbf{x}-\mathbf{b}\|_2^2` | |
| `np.trace(A)` | `\text{tr}(\mathbf{A})=\sum_i A_{ii}` | |
| `A.T` | `\mathbf{A}^\top` | |
| `np.conj(A).T` | `\mathbf{A}^*` | conjugate transpose |
| `np.kron(A, B)` | `\mathbf{A}\otimes\mathbf{B}` | Kronecker product |
| `np.cross(a, b)` | `\mathbf{a}\times\mathbf{b}` | 3-D only |
### NumPy element-wise
| Call | Notation |
|---|---|
| `a * b` (arrays) | `\mathbf{a}\odot\mathbf{b}` |
| `np.multiply(a, b)` | `\mathbf{a}\odot\mathbf{b}` |
| `np.power(a, n)` | `\mathbf{a}^n` (element-wise) |
| `np.sqrt(x)` | `\sqrt{x}` |
| `np.abs(x)` | `|x|` |
| `np.sign(x)` | `\text{sgn}(x)` |
| `np.clip(x, a, b)` | `\min(\max(x,a),b)` |
| `np.maximum(a, b)` | `\max(a,b)` |
| `np.minimum(a, b)` | `\min(a,b)` |
### NumPy exponential / log
| Call | Notation | Notes |
|---|---|---|
| `np.exp(x)` | `e^x` or `\exp(x)` | |
| `np.log(x)` | `\ln x` | natural log — not `log₁₀` |
| `np.log2(x)` | `\log_2 x` | information theory |
| `np.log10(x)` | `\log_{10} x` | |
| `np.log1p(x)` | `\ln(1+x)` | stable for small x |
| `np.expm1(x)` | `e^x-1` | stable for small x |
### NumPy statistical
| Call | Notation |
|---|---|
| `np.sum(x)` | `\sum_i x_i` |
| `np.prod(x)` | `\prod_i x_i` |
| `np.mean(x)` | `\bar{x}=\frac{1}{n}\sum_{i=1}^n x_i` |
| `np.var(x)` | `\sigma^2=\frac{1}{n}\sum_{i=1}^n(x_i-\bar{x})^2` |
| `np.var(x, ddof=1)` | `s^2=\frac{1}{n-1}\sum_{i=1}^n(x_i-\bar{x})^2` |
| `np.std(x)` | `\sigma_x` |
| `np.cov(X)` | `\boldsymbol{\Sigma}` (sample covariance, ddof=1) |
| `np.corrcoef(X)` | `\mathbf{R}` (correlation matrix) |
| `np.median(x)` | `\text{median}(\mathbf{x})` |
| `np.max(x)` | `\max_i x_i` |
| `np.argmax(x)` | `\operatorname{argmax}_i\,x_i` |
| `np.min(x)` | `\min_i x_i` |
| `np.argmin(x)` | `\operatorname{argmin}_i\,x_i` |
| `np.cumsum(x)` | `S_k=\sum_{i=1}^k x_i` |
| `np.cumprod(x)` | `P_k=\prod_{i=1}^k x_i` |
### NumPy combinatorics / trig / Fourier
| Call | Notation |
|---|---|
| `math.factorial(n)` | `n!` |
| `math.comb(n, k)` | `\binom{n}{k}` |
| `math.perm(n, k)` | `P(n,k)=\frac{n!}{(n-k)!}` |
| `np.sin(x)` | `\sin x` |
| `np.cos(x)` | `\cos x` |
| `np.tanh(x)` | `\tanh x` |
| `np.arctan2(y, x)` | `\operatorname{atan2}(y,x)` |
| `np.fft.fft(x)` | `X_k=\sum_{n=0}^{N-1}x_n e^{-2\pi ikn/N}` |
| `np.fft.ifft(X)` | `x_n=\frac{1}{N}\sum_{k=0}^{N-1}X_k e^{2\pi ikn/N}` |
| `np.convolve(a, b)` | `(a*b)[n]=\sum_k a[k]\,b[n-k]` |
### PyTorch layers
| Call | Notation |
|---|---|
| `nn.Linear(in,out)(x)` | `\mathbf{y}=\mathbf{W}\mathbf{x}+\mathbf{b}`, `\mathbf{W}\in\mathbb{R}^{\text{out}\times\text{in}}` |
| `nn.Conv2d(C_in,C_out,k)(x)` | `(x*w)_{c,i,j}=\sum_{c'}\sum_{m,n}w_{c,c',m,n}x_{c',i+m,j+n}` |
| `nn.MultiheadAttention(d,h)(Q,K,V)` | `\text{Attention}(\mathbf{Q},\mathbf{K},\mathbf{V})=\text{softmax}\!\left(\frac{\mathbf{Q}\mathbf{K}^\top}{\sqrt{d_k}}\right)\mathbf{V}` |
| `nn.LayerNorm()(x)` | `\frac{\mathbf{x}-\mu_\mathbf{x}}{\sigma_\mathbf{x}+\epsilon}\cdot\boldsymbol{\gamma}+\boldsymbol{\beta}` |
| `nn.BatchNorm1d()(x)` | `\frac{\mathbf{x}-\hat{\mu}}{\sqrt{\hat{\sigma}^2+\epsilon}}\cdot\boldsymbol{\gamma}+\boldsymbol{\beta}` |
| `nn.Dropout(p)(x)` | `\mathbf{x}\odot\mathbf{m}`, `m_i\sim\text{Bernoulli}(1-p)` |
### PyTorch activations
| Call | Notation |
|---|---|
| `F.relu(x)` | `\text{ReLU}(x)=\max(0,x)` |
| `F.leaky_relu(x,α)` | `\max(\alpha x,x)` |
| `F.sigmoid(x)` | `\sigma(x)=\frac{1}{1+e^{-x}}` |
| `F.tanh(x)` | `\tanh x` |
| `F.softmax(x,dim=-1)` | `\text{softmax}(\mathbf{x})_i=\frac{e^{x_i}}{\sum_j e^{x_j}}` |
| `F.log_softmax(x,dim=-1)` | `x_i-\log\sum_j e^{x_j}` |
| `F.gelu(x)` | `x\cdot\Phi(x)` (`\Phi` = standard normal CDF) |
| `F.silu(x)` | `x\cdot\sigma(x)` |
| `F.elu(x,α)` | `\begin{cases}x & x>0\\\alpha(e^x-1)&x\leq 0\end{cases}` |
### PyTorch losses
| Call | Notation |
|---|---|
| `F.mse_loss(y_hat,y)` | `\mathcal{L}_\text{MSE}=\frac{1}{n}\sum_{i=1}^n(\hat{y}_i-y_i)^2` |
| `F.l1_loss(y_hat,y)` | `\frac{1}{n}\sum_{i=1}^n|\hat{y}_i-y_i|` |
| `F.cross_entropy(logits,y)` | `\mathcal{L}_\text{CE}=-\sum_i y_i\ln\hat{p}_i` (includes softmax) |
| `F.binary_cross_entropy(p,y)` | `-\frac{1}{n}\sum_i[y_i\ln p_i+(1-y_i)\ln(1-p_i)]` |
| `F.kl_div(log_p,q)` | `D_\text{KL}(q\|p)=\sum_i q_i\ln\frac{q_i}{p_i}` |
| `F.huber_loss(y_hat,y,δ)` | `\begin{cases}\frac{1}{2}r^2&|r|\leq\delta\\\delta(|r|-\frac{\delta}{2})&|r|>\delta\end{cases}` |
| `F.cosine_similarity(a,b)` | `\frac{\mathbf{a}^\top\mathbf{b}}{\|\mathbf{a}\|_2\|\mathbf{b}\|_2}` |
### PyTorch optimizers (update rules)
| Optimizer | Update rule |
|---|---|
| `optim.SGD(lr=η)` | `\boldsymbol{\theta}_{t+1}=\boldsymbol{\theta}_t-\eta\nabla_{\boldsymbol{\theta}}\mathcal{L}` |
| `optim.SGD(lr=η,momentum=β)` | `\mathbf{v}_{t+1}=\beta\mathbf{v}_t+\nabla\mathcal{L}$; $\boldsymbol{\theta}_{t+1}=\boldsymbol{\theta}_t-\eta\mathbf{v}_{t+1}` |
| `optim.Adam(lr=η,betas=(β1,β2))` | `\hat{\mathbf{m}}_t=\frac{\mathbf{m}_t}{1-\beta_1^t}$; $\hat{\mathbf{v}}_t=\frac{\mathbf{v}_t}{1-\beta_2^t}$; $\boldsymbol{\theta}_{t+1}=\boldsymbol{\theta}_t-\frac{\eta\hat{\mathbf{m}}_t}{\sqrt{\hat{\mathbf{v}}_t}+\epsilon}` |
| `optim.AdaGrad(lr=η)` | `\boldsymbol{\theta}_{t+1}=\boldsymbol{\theta}_t-\frac{\eta}{\sqrt{\mathbf{G}_t+\epsilon}}\odot\nabla\mathcal{L}` |
| `optim.RMSProp(lr=η,alpha=α)` | `\mathbf{v}_t=\alpha\mathbf{v}_{t-1}+(1-\alpha)(\nabla\mathcal{L})^2$; $\boldsymbol{\theta}_{t+1}=\boldsymbol{\theta}_t-\frac{\eta}{\sqrt{\mathbf{v}_t+\epsilon}}\nabla\mathcal{L}` |
### R
| Call | Notation |
|---|---|
| `A %*% B` | `\mathbf{A}\mathbf{B}` |
| `t(A)` | `\mathbf{A}^\top` |
| `crossprod(A,B)` | `\mathbf{A}^\top\mathbf{B}` |
| `solve(A)` | `\mathbf{A}^{-1}` |
| `solve(A,b)` | `\mathbf{x}` s.t. `\mathbf{A}\mathbf{x}=\mathbf{b}` |
| `det(A)` | `\det(\mathbf{A})` |
| `svd(A)` | `\mathbf{A}=\mathbf{U}\boldsymbol{\Sigma}\mathbf{V}^\top` |
| `mean(x)` | `\bar{x}` |
| `var(x)` | `s^2` (sample, ddof=1) |
| `cov(X)` | `\mathbf{S}` |
| `log(x)` | `\ln x` |
| `choose(n,k)` | `\binom{n}{k}` |
### Julia
| Call | Notation |
|---|---|
| `A * B` (matrices) | `\mathbf{A}\mathbf{B}` |
| `A .* B` | `\mathbf{A}\odot\mathbf{B}` |
| `A'` | `\mathbf{A}^\top` |
| `(X'X) \ (X'y)` | OLS: `(\mathbf{X}^\top\mathbf{X})^{-1}\mathbf{X}^\top\mathbf{y}` |
| `dot(a,b)` | `\mathbf{a}^\top\mathbf{b}` |
| `norm(x)` | `\|\mathbf{x}\|_2` |
| `inv(A)` | `\mathbf{A}^{-1}` |
| `det(A)` | `\det(\mathbf{A})` |
| `tr(A)` | `\text{tr}(\mathbf{A})` |
| `kron(A,B)` | `\mathbf{A}\otimes\mathbf{B}` |
### SciPy distributions
| Call | Notation |
|---|---|
| `scipy.stats.norm(mu,sigma)` | `\mathcal{N}(\mu,\sigma^2)` |
| `scipy.stats.multivariate_normal(mu,Sigma)` | `\mathcal{N}(\boldsymbol{\mu},\boldsymbol{\Sigma})` |
| `scipy.stats.binom(n,p)` | `\text{Binomial}(n,p)` |
| `scipy.stats.poisson(lam)` | `\text{Poisson}(\lambda)` |
| `scipy.stats.beta(a,b)` | `\text{Beta}(\alpha,\beta)` |
| `scipy.stats.dirichlet(alpha)` | `\text{Dir}(\boldsymbol{\alpha})` |
| `scipy.stats.chi2(df)` | `\chi^2_k` |
| `.pdf(x)` | `p(x)` (density) |
| `.pmf(x)` | `P(X=x)` (mass) |
| `.cdf(x)` | `F(x)=P(X\leq x)` |
| `.ppf(q)` | `F^{-1}(q)` |
| `.rvs(size=n)` | `x_1,\ldots,x_n\overset{\text{i.i.d.}}{\sim}\text{dist}` |
| `.logpdf(x)` | `\ln p(x)` |
### SciPy optimization / integration
| Call | Notation |
|---|---|
| `scipy.optimize.minimize(f,x0)` | `\min_{\mathbf{x}}f(\mathbf{x})` |
| `scipy.optimize.linprog(c,A_ub,b_ub)` | `\min_{\mathbf{x}}\mathbf{c}^\top\mathbf{x}$ s.t. $\mathbf{A}\mathbf{x}\leq\mathbf{b}` |
| `scipy.integrate.quad(f,a,b)` | `\int_a^b f(x)\,dx` |
| `scipy.integrate.dblquad(f,...)` | `\iint f(x,y)\,dx\,dy` |
| `scipy.integrate.odeint(f,y0,t)` | `\frac{dy}{dt}=f(y,t)`, `y(0)=y_0` |
| `scipy.misc.derivative(f,x0)` | `f'(x_0)\approx\frac{f(x_0+h)-f(x_0-h)}{2h}` |
---
## §REF-NOTATION — Notation Conventions by Domain
Use the conventions below when the user's code or formula does not already impose a specific choice. If the input already uses a convention, preserve it.
### Machine Learning / Deep Learning
| Symbol | Type | Meaning |
|---|---|---|
| `\mathbf{x}` | vector | input / feature vector |
| `\mathbf{y}` | vector | target / label vector |
| `\hat{\mathbf{y}}` | vector | prediction |
| `\mathbf{W}` | matrix | weight matrix |
| `\mathbf{b}` | vector | bias vector |
| `\boldsymbol{\theta}` | vector | all parameters |
| `\boldsymbol{\phi}` | vector | encoder / variational parameters |
| `\mathbf{z}` | vector | latent variable / logits |
| `\mathbf{h}` | vector | hidden state |
| `\mathbf{Q},\mathbf{K},\mathbf{V}` | matrices | query, key, value (attention) |
| `d_k` | scalar | key/query dimension |
| `n` | scalar | number of training examples |
| `d` | scalar | input dimensionality |
| `C` | scalar | number of classes |
| `\mathcal{L}` | scalar | loss (not `L`) |
| `\eta` | scalar | learning rate (not `lr`) |
| `\lambda` | scalar | regularization coefficient |
| `\beta_1,\beta_2` | scalar | Adam momentum coefficients |
| `\epsilon` | scalar | numerical stability constant |
| `\mathbf{g}` | vector | gradient `\nabla_{\boldsymbol{\theta}}\mathcal{L}` |
**Idioms:** loss → `\mathcal{L}` not `L`; predictions → `\hat{y}` not `y_pred`; gradient → `\nabla_{\boldsymbol{\theta}}\mathcal{L}` not `dL/dtheta`; training set → `\mathcal{D}=\{(\mathbf{x}_i,y_i)\}_{i=1}^n`; logits → `\mathbf{z}`.
### Statistics and Probability
| Symbol | Meaning |
|---|---|
| `X,Y,Z` | random variables (uppercase italic) |
| `x,y,z` | observed values (lowercase italic) |
| `\mu` | population mean |
| `\sigma^2` | population variance |
| `\bar{x}` | sample mean |
| `s^2` | sample variance (Bessel-corrected) |
| `\hat{\theta}` | estimator of `\theta` |
| `\mathcal{L}(\theta)` | likelihood |
| `\ell(\theta)` | log-likelihood |
**Distributions:** `X\sim\mathcal{N}(\mu,\sigma^2)` · `\mathcal{N}(\boldsymbol{\mu},\boldsymbol{\Sigma})` · `\text{Bernoulli}(p)` · `\text{Binomial}(n,p)` · `\text{Poisson}(\lambda)` · `\text{Beta}(\alpha,\beta)` · `\text{Dir}(\boldsymbol{\alpha})` · `\chi^2_k` · `t_k`
**Idioms:** conditional → `P(A\mid B)` (use `\mid` not `|`); independence → `X\perp\!\!\!\perp Y`; expectation → `\mathbb{E}[X]`; variance → `\text{Var}(X)`; KL → `D_\text{KL}(P\|Q)=\sum_x P(x)\ln\frac{P(x)}{Q(x)}`; entropy → `H(X)=-\sum_x P(x)\ln P(x)`.
### Linear Algebra and Matrix Analysis
| Symbol | Type | Meaning |
|---|---|---|
| `a,b,c` | lowercase italic | scalars |
| `\mathbf{u},\mathbf{v},\mathbf{w}` | bold lowercase | vectors |
| `\mathbf{A},\mathbf{B},\mathbf{C}` | bold uppercase | matrices |
| `\mathbf{I}` | bold | identity matrix |
| `\lambda_i` | scalar | eigenvalues |
| `\mathbf{v}_i` | vector | eigenvectors |
| `\sigma_i` | scalar | singular values |
| `\mathbf{U},\mathbf{V}` | matrices | orthogonal (SVD) |
| `\boldsymbol{\Sigma}` | diagonal | singular values (SVD) |
**Idioms:** transpose → `\mathbf{A}^\top` (not `^T`); inverse → `\mathbf{A}^{-1}`; pseudoinverse → `\mathbf{A}^+`; Frobenius → `\|\mathbf{A}\|_F`; spectral → `\|\mathbf{A}\|_2=\sigma_\max`; nuclear → `\|\mathbf{A}\|_*=\sum_i\sigma_i`; inner product → `\langle\mathbf{u},\mathbf{v}\rangle=\mathbf{u}^\top\mathbf{v}`.
### Optimization
| Symbol | Meaning |
|---|---|
| `f(\mathbf{x})` | objective |
| `\mathbf{x}^*` | optimal solution |
| `\mathcal{X}` | feasible set |
| `g(\mathbf{x})\leq 0` | inequality constraint |
| `h(\mathbf{x})=0` | equality constraint |
| `\boldsymbol{\lambda},\boldsymbol{\nu}` | Lagrange multipliers |
| `\eta_t` | step size at iteration t |
**Idioms:** LP standard form → `\min_\mathbf{x}\mathbf{c}^\top\mathbf{x}$ s.t. $\mathbf{A}\mathbf{x}=\mathbf{b},\mathbf{x}\geq\mathbf{0}`; subgradient → `\mathbf{g}\in\partial f(\mathbf{x})`; proximal → `\text{prox}_f(\mathbf{v})=\operatorname{argmin}_\mathbf{x}(f(\mathbf{x})+\frac{1}{2}\|\mathbf{x}-\mathbf{v}\|^2)`.
### Signal Processing
**Symbols:** `x[n]` discrete signal · `X[k]` DFT coefficient · `h[n]` impulse response · `N` length · `\omega` angular frequency · `*` convolution (this context only)
**Idioms:** DFT → `X[k]=\sum_{n=0}^{N-1}x[n]e^{-j2\pi kn/N}` (use `j` for imaginary unit in engineering); convolution → `(x*h)[n]=\sum_k x[k]\,h[n-k]`.
### Graph Theory
**Symbols:** `G=(V,E)` graph · `\mathbf{A}` adjacency matrix · `\mathbf{D}` degree matrix · `\mathbf{L}=\mathbf{D}-\mathbf{A}` Laplacian · `d_i` degree · `N(v)` neighborhood · `w_{ij}` edge weight · `\pi` stationary distribution.
### Information Theory
| Symbol | Meaning |
|---|---|
| `H(X)` | Shannon entropy: `-\sum_x p(x)\log_2 p(x)` |
| `H(X\mid Y)` | conditional entropy |
| `I(X;Y)` | mutual information |
| `D_\text{KL}(P\|Q)` | KL divergence |
| `D_\text{JS}(P\|Q)` | Jensen-Shannon divergence |
| `H_b(p)` | binary entropy |
Use `\log_2` for bits; `\ln` for nats (ML/statistics).
### Numerical Methods
**Symbols:** `h` step size · `e_n` error at step n · `\epsilon_\text{mach}` machine epsilon · `\kappa(\mathbf{A})` condition number · `O(h^p)` convergence order
**Idioms:** forward diff → `f'(x)\approx\frac{f(x+h)-f(x)}{h}`; centered → `\frac{f(x+h)-f(x-h)}{2h}`; second deriv → `\frac{f(x+h)-2f(x)+f(x-h)}{h^2}`; Euler → `y_{n+1}=y_n+h\,f(t_n,y_n)`.
---
## §REF-TEMPLATES — LaTeX Templates
### Single equation
```latex
\[
<formula>
\]
```
### Multi-line aligned
```latex
\begin{align}
f(x) &= <step 1> \\
&= <step 2> \\
&= <final>
\end{align}
```
### Piecewise function
```latex
f(x) = \begin{cases}
<expr_1> & \text{if } <cond_1> \\
<expr_2> & \text{if } <cond_2> \\
<expr_3> & \text{otherwise}
\end{cases}
```
### Generic m × n matrix
```latex
\mathbf{A} = \begin{bmatrix}
a_{11} & \cdots & a_{1n} \\
\vdots & \ddots & \vdots \\
a_{m1} & \cdots & a_{mn}
\end{bmatrix} \in \mathbb{R}^{m \times n}
```
### Column vector
```latex
\mathbf{x} = \begin{bmatrix} x_1 \\ \vdots \\ x_n \end{bmatrix} \in \mathbb{R}^n
```
### Block matrix
```latex
\mathbf{M} = \begin{bmatrix} \mathbf{A} & \mathbf{B} \\ \mathbf{C} & \mathbf{D} \end{bmatrix}
```
### Optimization problem
```latex
\begin{align}
&\underset{\mathbf{x}}{\text{minimize}} && f(\mathbf{x}) \\
&\text{subject to} && g_i(\mathbf{x}) \leq 0, \quad i = 1,\ldots,m \\
& && h_j(\mathbf{x}) = 0, \quad j = 1,\ldots,p
\end{align}
```
### Statistical model (generative story)
```latex
\begin{align}
\boldsymbol{\mu} &\sim \mathcal{N}(\mathbf{0}, \sigma_0^2 \mathbf{I}) \\
\mathbf{x}_i \mid \boldsymbol{\mu} &\overset{\text{i.i.d.}}{\sim} \mathcal{N}(\boldsymbol{\mu}, \sigma^2 \mathbf{I}), \quad i = 1,\ldots,n
\end{align}
```
### Gradient / Jacobian / Hessian
```latex
% Gradient
\nabla f(\mathbf{x}) = \begin{bmatrix}
\frac{\partial f}{\partial x_1} \\ \vdots \\ \frac{\partial f}{\partial x_n}
\end{bmatrix}
% Jacobian
\mathbf{J}_f(\mathbf{x}) = \begin{bmatrix}
\frac{\partial f_1}{\partial x_1} & \cdots & \frac{\partial f_1}{\partial x_n} \\
\vdots & \ddots & \vdots \\
\frac{\partial f_m}{\partial x_1} & \cdots & \frac{\partial f_m}{\partial x_n}
\end{bmatrix}
% Hessian
\mathbf{H}_f(\mathbf{x}) = \begin{bmatrix}
\frac{\partial^2 f}{\partial x_1^2} & \cdots & \frac{\partial^2 f}{\partial x_1 \partial x_n} \\
\vdots & \ddots & \vdots \\
\frac{\partial^2 f}{\partial x_n \partial x_1} & \cdots & \frac{\partial^2 f}{\partial x_n^2}
\end{bmatrix}
```
### Norms
```latex
\|\mathbf{x}\|_0 = |\{i : x_i \neq 0\}|
\|\mathbf{x}\|_1 = \sum_{i=1}^n |x_i|
\|\mathbf{x}\|_2 = \sqrt{\sum_{i=1}^n x_i^2}
\|\mathbf{x}\|_p = \left(\sum_{i=1}^n |x_i|^p\right)^{1/p}
\|\mathbf{x}\|_\infty = \max_i |x_i|
\|\mathbf{A}\|_F = \sqrt{\sum_{i,j} A_{ij}^2} = \sqrt{\text{tr}(\mathbf{A}^\top \mathbf{A})}
```
### Recurrence relation
```latex
a_n = f(a_{n-1}, a_{n-2}, \ldots), \quad a_0 = c_0,\quad a_1 = c_1
```
### Standalone export document
```latex
\documentclass{article}
\usepackage{amsmath, amssymb, mathtools, bm}
\usepackage{booktabs}
\title{<Formula Title>}
\begin{document}
\maketitle
\section*{Formula}
\[ <formula> \]
\section*{Symbol Definitions}
\begin{tabular}{lll}
\toprule
Symbol & Type & Meaning \\ \midrule
<rows> \\ \bottomrule
\end{tabular}
\section*{Explanation}
<text>
\end{document}
```Discussion (0)
to join the discussion.
No comments yet. Be the first to discuss this paper.