# PolymathPlus AI Context This single file contains the complete approved public PolymathPlus AI documentation set in one pasteable Markdown document. It is intended for users who want to provide all PolymathPlus AI guidance to ChatGPT, Gemini, Claude, Copilot, or another LLM without relying on the LLM to fetch external links. Primary objective: help students and engineers describe a problem in natural language, then have an AI generate valid PolymathPlus source. Completeness note: the source documents below are included in full. No approved public documentation content was intentionally omitted. Use `polymathplus` fenced code blocks as real PolymathPlus source. Use `txt` fenced code blocks as plain text, prompts, paths, or non-source examples. ## Included Documents - `polymathplus-llm-guide.md` - `agent-instructions.md` - `examples.md` - `error-fixing-guide.md` - `spec_leq.md` - `spec_nle.md` - `spec_deq.md` - `spec_reg.md` - `spec_nlp.md` ## Public Documentation URLs - https://www.polymathplus.org/ai/polymathplus-llm-guide.md - https://www.polymathplus.org/ai/agent-instructions.md - https://www.polymathplus.org/ai/examples.md - https://www.polymathplus.org/ai/error-fixing-guide.md - https://www.polymathplus.org/ai/spec_leq.md - https://www.polymathplus.org/ai/spec_nle.md - https://www.polymathplus.org/ai/spec_deq.md - https://www.polymathplus.org/ai/spec_reg.md - https://www.polymathplus.org/ai/spec_nlp.md --- # PolymathPlus LLM Guide ## Purpose This guide helps students and engineers describe a numerical problem in natural language, then have an AI generate valid PolymathPlus source. Use this file as the entry point for LLM-assisted modeling. Related resources: - [Examples](examples.md): prompt patterns and valid PolymathPlus source examples - [Error Fixing Guide](error-fixing-guide.md): repair patterns for validator and solver errors - [Agent Instructions](agent-instructions.md): operational workflow for coding agents - [Linear & Explicit Equations Spec](spec_leq.md): linear equations - [Nonlinear Equations Spec](spec_nle.md): nonlinear equations and expression evaluation - [Differential Equations Spec](spec_deq.md): ordinary differential equations - [Regression Spec](spec_reg.md): regression and tabular integration - [Optimization Spec](spec_nlp.md): nonlinear programming and least-squares optimization Do not invent syntax from this guide. When exact syntax matters, follow the relevant linked spec file. ## Modeling Workflow When converting a natural-language problem into PolymathPlus source: 1. Identify the numerical problem type. 2. Extract known constants, unknown variables, equations, tables, initial values, guesses, bounds, and constraints. 3. Choose exactly one PolymathPlus program type. 4. Write the smallest valid source program that represents the model. 5. Run precheck validation. 6. Repair syntax or modeling errors using validator feedback. 7. Solve the validated program. 8. Explain the result in terms of the original problem. ## Program Type Selection Choose `LEQ` when the problem is a linear algebraic system: - unknowns appear only to the first power - unknowns are not multiplied by each other - every equation is linear Choose `NLE` when the goal is to evaluate expressions or solve nonlinear equations: - expression-calculator style helper equations - one nonlinear root equation - simultaneous nonlinear root equations Choose `DEQ` when the problem has ordinary differential equations: - derivatives such as `d(C)/d(t)` or `C'` - initial values - final time or independent-variable range Choose `REG` when the problem fits tabular data using built-in regression/integration commands: - `polyfit` - `mlinfit` - `nlinfit` - `integrate` Choose `NLP` when the problem is optimization: - table-free minimization with `min:` - constrained optimization - least-squares optimization with `fit:` when NLP bounds or constraints are needed If more than one type seems possible, choose the type by the required top-level syntax: LEQ equations only, NLE `f(variable)` roots or expression evaluation, DEQ derivatives, REG table plus regression/integration command, or NLP `min:`/`fit:` optimization. ## Common Generation Rules For all program types: - Use one program type per source file. - Use `#` for comments. - Use variable names that start with a letter and contain only letters, digits, and underscores. - Avoid built-in function names and conditional keywords as variable names. - Prefer explicit multiplication with `*`. - Keep examples small unless the real problem requires more detail. - Do not mix tables, derivatives, regression commands, optimization statements, and root-equation syntax unless the chosen spec allows that combination. ## Modeling Patterns Linear mass balance: ```polymathplus 2*A + B = 10 A - B = 1 ``` Nonlinear single root: ```polymathplus f(x) = x*log(x/2) + 4*x^2 - 1620 x(min) = 0.1 x(max) = 100 ``` Ordinary differential equation: ```polymathplus d(A)/d(t) = -k*A k = 0.3 A(0) = 10 t(0) = 0 t(f) = 5 ``` Regression from data: ```polymathplus [ x y 1 2.1 2 4.2 3 8.1 4 16.3 ] polyfit x y 2 ``` Optimization: ```polymathplus min: (x - 2)^2 + (y - 3)^2 x + y - 4 = 0 x| 1 0 10 y| 1 0 10 ``` ## Prompt Pattern For Manual LLM Use Use this prompt shape with ChatGPT, Gemini, Claude, Copilot, or another assistant: ```txt Convert the following problem into valid PolymathPlus source. First choose the program type: LEQ, NLE, DEQ, REG, or NLP. Then list the variables, constants, equations, data table, guesses, bounds, and constraints. Then output only the PolymathPlus source in one code block. Follow the relevant PolymathPlus spec and do not invent syntax. Problem: ``` For repair after validation: ```txt The following PolymathPlus source failed precheck. Repair it using the validator messages. Keep the same mathematical intent and output only the corrected source. Source: Validator messages: ``` ## Validation And Repair Always validate generated source before solving. When validation fails: - Read the first error message carefully. - Identify whether the issue is syntax, missing data, unknown variables, duplicate definitions, unsupported program mixing, or invalid bounds/constraints. - Repair the smallest part of the program that explains the error. - Re-run validation after every repair. - Do not change the mathematical model unless the validator error reveals an actual modeling ambiguity. Common repairs: - Unknown variable: define it or correct the spelling. - Duplicate variable: keep only one definition. - Mixed program styles: choose one program type and remove incompatible syntax. - Invalid table: fix header names and row column counts. - Invalid NLP constraint: follow `spec_nlp.md`; write equality constraints as `residual = 0`, inequalities as `residual > 0`, and do not use `>=`, `<=`, or nonzero inequality right-hand sides. - Missing guesses, bounds, or ranges: add only the required lines for the selected program type, following the relevant `spec_*.md`. - Circular helper equations: break the dependency loop. ## Documentation Map Use the detailed specs as the source for exact syntax: - For linear systems, use `spec_leq.md`. - For nonlinear equations, use `spec_nle.md`. - For ODEs, use `spec_deq.md`. - For regression and integration, use `spec_reg.md`. - For optimization and least-squares fitting, use `spec_nlp.md`. Use later repo docs for specialized workflows: - `agent-instructions.md`: instructions for AI agents generating PolymathPlus source - `examples.md`: canonical examples grouped by program type - `error-fixing-guide.md`: validator-message repair patterns --- # PolymathPlus Agent Instructions ## Purpose Use these instructions when an AI agent converts a student or engineering problem statement into valid PolymathPlus source. Primary objective: Help students and engineers describe a problem in natural language, then generate valid PolymathPlus source that can pass precheck and be solved. This file is an operational prompt/instruction pack. It is not the detailed syntax source of truth. For exact syntax, follow: - `spec_leq.md` - `spec_nle.md` - `spec_deq.md` - `spec_reg.md` - `spec_nlp.md` ## Agent Responsibilities When given a problem statement: 1. Identify the numerical problem type. 2. Extract variables, constants, equations, data, initial values, guesses, bounds, ranges, and constraints. 3. Decide whether the problem is supported directly by PolymathPlus. 4. Select exactly one PolymathPlus program type when supported. 5. Generate valid PolymathPlus source using the relevant spec only when the model has the required inputs. 6. Avoid unsupported syntax and mixed program styles. 7. Ask a focused clarification question when required model information is missing. 8. If validator messages are provided, repair the source with the smallest change that preserves the intended model. ## Required Reasoning Steps Before writing source, determine: - What is being solved or computed? - What are the known values? - What are the unknowns or decision variables? - Are there equations, derivatives, tabular data, constraints, guesses, bounds, or ranges? - Which one program type matches the required top-level syntax? - Is the problem directly supported by LEQ, NLE, DEQ, REG, or NLP? - Are any required inputs missing before valid source can be generated? - Is the user asking for a composite workflow that would require more than one program type or chained solves? Do not expose long reasoning in the final answer unless the user asks. A short model summary is useful before the source when the user has not requested source-only output. ## Program Type Routing Choose `LEQ` for linear algebraic systems: - equations only - unknowns are linear - no products of unknowns - no derivatives, tables, optimization statements, or nonlinear root declarations Choose `NLE` for nonlinear equations and expression evaluation: - expression-calculator style programs - one root equation using `f(x)` - simultaneous nonlinear equations using one `f(variable)` root line per nonlinear variable, such as `f(x)` and `f(y)` Choose `DEQ` for ordinary differential equations: - derivative lines such as `d(A)/d(t)` or prime notation - initial values - final independent-variable value or range Choose `REG` for table-based regression or tabular integration: - one data table - one command: `polyfit`, `mlinfit`, `nlinfit`, or `integrate` Choose `NLP` for optimization: - `min:` objective programs - constrained optimization - `fit:` least-squares optimization when NLP-style bounds or constraints are needed If more than one type seems possible, choose by required top-level syntax: - LEQ: equations only - NLE: nonlinear root declarations or expression evaluation - DEQ: derivatives - REG: table plus regression/integration command - NLP: `min:` or NLP `fit:` optimization ## No Composite Programs PolymathPlus source generation must target one singular, fully supported program type. Do not generate a composite program that: - solves an LEQ problem and feeds the result into a DEQ problem - solves an NLE problem and feeds the result into REG or NLP - combines regression with optimization in one generated source program - mixes ODE solving with algebraic solving as separate stages - chains multiple PolymathPlus solves together inside one source file If the user asks for a multi-stage workflow, split the response conceptually but generate only one supported program at a time. Required behavior: 1. Explain that PolymathPlus precheck expects one identifiable program type per source program. 2. Ask which stage the user wants to generate first, or choose the first stage only if the user explicitly asked for it. 3. Generate source only for that one selected stage. 4. Do not imply that one PolymathPlus source file can run the full chained workflow. ## Support Decision Before generating source, classify the request as one of: 1. Directly supported. 2. Supported only after missing required inputs are provided. 3. Possibly supported after reformulation or approximation. 4. Not supported by current PolymathPlus program types. 5. Composite workflow that must be split into separate single-type programs. Generate PolymathPlus source only for cases 1 and 2 after required inputs are available. For case 3, explain the limitation and ask whether the user wants a supported reformulation. For case 4, state that PolymathPlus does not directly support the requested problem type and do not invent syntax. For case 5, explain that a single PolymathPlus source program cannot solve chained program types. Ask which single stage to generate first. ## Unsupported Or Out-Of-Scope Problems PolymathPlus source generation is limited to the supported program types: - LEQ - NLE - DEQ - REG - NLP Do not generate PolymathPlus source for unsupported problem types unless the user explicitly agrees to a valid reformulation. Examples of unsupported or not-directly-supported requests include: - partial differential equations - differential-algebraic equations when they cannot be written as supported ODEs - stochastic simulation or Monte Carlo workflows - symbolic algebra proofs or symbolic closed-form solving - discrete optimization, integer programming, or mixed-integer programming - matrix eigenvalue/eigenvector problems unless reformulated as a supported equation system - optimization with unsupported discrete decisions or nonsupported constraint forms When the request is unsupported: 1. State the limitation plainly. 2. Name the closest supported PolymathPlus program types, if any. 3. Offer a reformulation only when it is mathematically reasonable. 4. Ask the user whether to proceed with that reformulation. 5. Do not fabricate commands, solver options, or syntax. Example response shape: ````txt PolymathPlus does not directly support PDE source programs. It supports LEQ, NLE, DEQ, REG, and NLP. If you discretize the PDE into algebraic equations or ODEs, I can help build a supported LEQ, NLE, or DEQ formulation. Please specify the discretization or confirm that you want help choosing one. ```` ## Missing Required Inputs Some supported program types require modeling inputs that are not optional. Common required inputs: - NLE1 root solving requires bounds such as `x(min)` and `x(max)`. - NLES simultaneous nonlinear equations require initial guesses for nonlinear variables. - DEQ requires initial values and a final value or range for the independent variable. - REG requires the data table and the appropriate command inputs. - REG `nlinfit` requires initial guesses for fitted parameters. - NLP requires guess/bounds lines for model variables. - NLP constraints must already be expressible as supported residual constraints. When required inputs are missing: 1. Do not pretend the missing value is known. 2. Ask for the missing value if it is a real modeling input. 3. If a heuristic value could be used, label it clearly as an initial guess or modeling assumption. 4. Do not present heuristic guesses as derived facts. 5. Generate final source only after the user provides the input or explicitly accepts the assumption. Initial guesses: - Initial guesses are solver starting points, not guaranteed answers. - If the user does not know a required initial guess, explain why PolymathPlus needs it. - Offer a practical strategy when possible: - use values near the expected physical operating point - use measured or nominal engineering values - use values from a simpler approximation - use several different starting guesses if convergence is uncertain - Ask the user to approve any guessed values before treating them as final source. Example response shape: ````txt This is a supported NLES problem, but PolymathPlus requires an initial guess for each nonlinear variable. I should not invent those as known data. Provide starting guesses for x and y, or confirm that I should use heuristic guesses based on the scale of the equations. ```` ## Source Generation Rules Always: - Generate one complete PolymathPlus program. - Use one singular, fully supported program type only. - Use `#` for comments. - Use variable names that start with a letter and contain only letters, digits, and underscores. - Avoid variable names that are built-in functions or keywords. - Prefer explicit multiplication with `*`. - Keep output small and directly tied to the problem. - Use the relevant `spec_*.md` file for exact syntax. - State when source generation is blocked by unsupported problem type or missing required inputs. Never: - Mix derivatives with tables or regression commands. - Mix `min:` or `fit:` optimization with unrelated equation-system syntax. - Build a composite source file that chains LEQ, NLE, DEQ, REG, or NLP solves. - Use unsupported constraint syntax such as `>=` or `<=` in NLP. - Invent commands, metadata, or solver options. - Invent required data, initial conditions, guesses, bounds, ranges, or constraints and present them as facts. - Add explanatory prose inside a source-only code block. ## Output Format When generating a new program, use this structure unless the user asks for source only: ````txt Program type: Model summary: ```polymathplus ``` ```` When the user asks for source only, output only one fenced code block. ## Validation Workflow After generating source: 1. Run precheck only when a repo-provided or environment-provided precheck command is available; do not invent validator commands. 2. If precheck passes, report that the source validates. 3. If precheck fails, use the first validator error to guide repair. 4. Re-run precheck after repair. 5. Repeat until valid or until the model needs clarification. Do not change the mathematical intent just to satisfy syntax. If the source cannot be repaired without changing the model, ask the user for the missing modeling decision. ## Repair Rules For unknown variables: - Check for spelling differences. - Define the missing variable if it is a known constant or helper. - Add the required guess/bounds/range only if the selected program type requires it. For duplicate definitions: - Keep one definition. - Rename only when the variables are genuinely different concepts. For mixed program styles: - Choose the one program type that matches the problem. - Remove syntax from other program types. - If the request truly requires multiple stages, generate only one stage at a time and ask which stage to handle first. For invalid tables: - Fix duplicate headers. - Make every data row match the header column count. - Keep exactly one table when the selected program type uses a table. For NLP constraints: - Write equality constraints as `residual = 0`. - Write inequality constraints as `residual > 0`. - Do not use `>=`, `<=`, or nonzero inequality right-hand sides. - For a model variable constrained to zero, prefer `x - 0 = 0` instead of a bare `x = 0`. For circular helper equations: - Break the dependency loop only by algebraically rewriting the stated model or using a value already given in the problem. If that changes intent or requires a new assumption, ask for clarification. ## Program-Type Guardrails ### LEQ Use `spec_leq.md`. Generate only linear equations. Do not multiply unknowns by each other, raise unknowns to powers other than one, or use nonlinear functions of unknowns. ### NLE Use `spec_nle.md`. Choose the NLE subtype from the problem: - expression evaluation - single nonlinear root - simultaneous nonlinear roots Add initial guesses or bounds only in the form required by the selected subtype. ### DEQ Use `spec_deq.md`. Include: - derivative equations - initial values - independent-variable final value or range Keep one derivative notation style in the same program. ### REG Use `spec_reg.md`. Include: - one data table - one regression/integration command - initial guesses only when the chosen command requires them Use REG for ordinary table-based fitting before considering NLP `fit:`. ### NLP Use `spec_nlp.md`. Include: - one `min:` or `fit:` statement - guess/bounds lines for model variables - constraints only as `= 0` or `> 0` Use NLP when the problem is optimization or when fitting requires NLP-style constraints or bounds. ## Clarification Questions Ask a question before generating source when: - The problem type is unsupported unless reformulated. - The problem does not identify what should be solved, fitted, minimized, or integrated. - Data are referenced but not provided. - Initial conditions, ranges, guesses, bounds, or constraints are required but missing. - Two program types are equally plausible and would produce materially different models. - A reformulation or approximation is needed to fit a supported PolymathPlus program type. - The user asks for a chained workflow that would require multiple PolymathPlus program types. Keep clarification questions short and specific. ## Final Answer Expectations For users: - Provide the selected program type. - Provide valid source. - Mention validation status when known. - Keep explanations concise and tied to the original problem. For repair tasks: - Provide corrected source. - Briefly state what changed. - Do not introduce new modeling assumptions unless explicitly stated. --- # PolymathPlus Examples ## Purpose This file gives representative, validated examples for students, engineers, and AI agents that need to convert natural-language problems into valid PolymathPlus source. Use these examples for modeling patterns and prompt grounding. Use the detailed specs for exact syntax: - `spec_leq.md` - `spec_nle.md` - `spec_deq.md` - `spec_reg.md` - `spec_nlp.md` This file is intentionally not exhaustive. For less common subtypes such as REG `mlinfit`, REG `integrate`, and NLP `fit:`, use the detailed specs. Each example is one singular program type. Do not combine examples into a composite source file. ## LEQ: Linear Algebraic System Natural-language problem: Solve a two-equation linear balance system where `2*A + B = 10` and `A - B = 1`. Program type: `LEQ` ```polymathplus 2*A + B = 10 A - B = 1 ``` Modeling notes: - This is LEQ because all unknowns are linear. - There are no products of unknowns, derivatives, tables, or optimization statements. ## NLE0: Expression Evaluation Natural-language problem: Evaluate an engineering expression for pressure drop from known flow and resistance values. Program type: `NLE` ```polymathplus flow = 3.2 resistance = 4.5 pressure_drop = resistance*flow^2 ``` Modeling notes: - This is expression evaluation, not root solving. - No initial guesses or bounds are needed because there is no nonlinear root variable. ## NLE1: Single Nonlinear Root Natural-language problem: Find `x` such that `x*log(x/2) + 4*x^2 - 1620 = 0` on the interval from `0.1` to `100`. Program type: `NLE` ```polymathplus f(x) = x*log(x/2) + 4*x^2 - 1620 x(min) = 0.1 x(max) = 100 ``` Modeling notes: - This is NLE1 because there is one nonlinear root variable. - Bounds are required for the root variable. ## NLES: Simultaneous Nonlinear Roots Natural-language problem: Solve the nonlinear system `x^2 + y^2 = 25` and `x - y = 1`, using initial guesses near `x = 4` and `y = 3`. Program type: `NLE` ```polymathplus f(x) = x^2 + y^2 - 25 f(y) = x - y - 1 x(0) = 4 y(0) = 3 ``` Modeling notes: - This is NLES because there are simultaneous nonlinear root equations. - Initial guesses are required. - Use one `f(variable)` root line per nonlinear variable. ## DEQ: Ordinary Differential Equation Natural-language problem: A tank concentration `A` decays with first-order rate constant `k = 0.3`. The initial concentration is `10`. Simulate from `t = 0` to `t = 5`. Program type: `DEQ` ```polymathplus d(A)/d(t) = -k*A k = 0.3 A(0) = 10 t(0) = 0 t(f) = 5 ``` Modeling notes: - This is DEQ because it contains a derivative. - Initial and final values are required. ## REG: Polynomial Regression Natural-language problem: Fit a second-order polynomial to measured `x, y` data. Program type: `REG` ```polymathplus [ x y 1 2.1 2 4.2 3 8.1 4 16.3 5 25.2 ] polyfit x y 2 ``` Modeling notes: - This is REG because it uses a data table and a regression command. - Use REG for ordinary table-based fitting before considering NLP `fit:`. ## REG: Nonlinear Regression Natural-language problem: Fit the model `y = a*x/(b + x)` to measured data, starting from `a = 2` and `b = 1`. Program type: `REG` ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 ``` Modeling notes: - This is REG `nlinfit`. - Initial guesses are required for fitted parameters. ## NLP: Unconstrained Optimization Natural-language problem: Find `x` and `y` that minimize the squared distance from the point `(2, 3)`. Program type: `NLP` ```polymathplus min: (x - 2)^2 + (y - 3)^2 x| 1 0 10 y| 1 0 10 ``` Modeling notes: - This is NLP because it minimizes an objective. - Guess/bounds lines are required for model variables. ## NLP: Constrained Optimization Natural-language problem: Minimize distance from `(1, 1)` subject to `x + y = 1` and inside the circle `x^2 + y^2 <= 1.5`. Program type: `NLP` ```polymathplus min: (x - 1)^2 + (y - 1)^2 x + y - 1 = 0 1.5 - (x^2 + y^2) > 0 x| 0.5 -2 2 y| 0.5 -2 2 ``` Modeling notes: - Equality constraints use residual form: `residual = 0`. - Inequality constraints use residual form: `residual > 0`. - Do not use `>=`, `<=`, or nonzero inequality right-hand sides. ## Unsupported Example: PDE Request Natural-language problem: Solve a heat equation PDE in one spatial dimension and time. Program type: unsupported directly Recommended agent response: ```txt PolymathPlus does not directly support PDE source programs. It supports LEQ, NLE, DEQ, REG, and NLP. If you discretize the PDE into algebraic equations or ODEs, I can help build a supported LEQ, NLE, or DEQ formulation. Please specify the discretization or confirm that you want help choosing one. ``` Modeling notes: - Do not invent PDE syntax. - A supported source program can be generated only after a valid reformulation is selected. ## Missing Input Example: NLES Without Guesses Natural-language problem: Solve `x^2 + y^2 = 25` and `x - y = 1`. Program type: `NLE`, but blocked until initial guesses are provided. Recommended agent response: ```txt This is a supported NLES problem, but PolymathPlus requires an initial guess for each nonlinear variable. I should not invent those as known data. Provide starting guesses for x and y, or confirm that I should use heuristic guesses based on the scale of the equations. ``` Modeling notes: - Do not generate final NLES source without required guesses. - Heuristic guesses may be offered only as assumptions. --- # PolymathPlus Error Fixing Guide ## Purpose This guide helps users and AI agents repair PolymathPlus source after precheck validation reports an error. Primary objective: Help students and engineers move from natural-language problem statements to valid PolymathPlus source without inventing unsupported syntax or silently changing the mathematical model. Use this guide for repair workflow. Use the detailed specs for exact syntax: - `spec_leq.md` - `spec_nle.md` - `spec_deq.md` - `spec_reg.md` - `spec_nlp.md` ## Repair Principles Always: - Fix the first meaningful validator error before making broad edits. - Preserve the user's mathematical intent. - Make the smallest repair that explains the error. - Keep one singular, fully supported program type. - Re-run precheck after each repair when a validator is available. Never: - Invent required data, guesses, bounds, ranges, or constraints and present them as facts. - Convert an unsupported problem into PolymathPlus source without an explicit reformulation. - Build a composite source program that chains multiple program types. - Add unsupported syntax to satisfy a user request. ## Repair Workflow 1. Read the validator message. 2. Identify the error category. 3. Check the selected program type. 4. Repair only the relevant line or section. 5. Re-run precheck. 6. If the repair needs a modeling assumption, ask the user before generating final source. ## Unsupported Problem Type Symptoms: - The user asks for a problem outside LEQ, NLE, DEQ, REG, or NLP. - The problem requires PDEs, unsupported DAEs, stochastic simulation, symbolic solving, discrete optimization, or another unsupported workflow. Repair action: - Do not generate source. - State that the requested problem type is not directly supported. - Offer a supported reformulation only if it is mathematically reasonable. - Ask the user whether to proceed with the reformulation. Recommended response: ```txt PolymathPlus does not directly support this problem type. It supports LEQ, NLE, DEQ, REG, and NLP. I can help reformulate the problem into a supported type if you provide or approve the reformulation. ``` ## Composite Or Multi-Stage Workflow Symptoms: - The request needs one solve result to feed another solve. - The source would need to combine LEQ and DEQ, REG and NLP, or another chain of program types. Repair action: - Do not create one composite source file. - Explain that PolymathPlus precheck expects one identifiable program type per source program. - Ask which single stage to generate first. Recommended response: ```txt This is a multi-stage workflow. A single PolymathPlus source program must use one singular program type, so I cannot generate one file that solves both stages. Tell me which stage to generate first. ``` ## Unknown Variable Symptoms: - Validator reports an unknown variable. - A variable is used in an expression but is not defined by the selected program type's rules. Repair action: - Check spelling first. - Define a missing known constant or helper equation. - Add a required guess, bound, initial value, range, or table column only when the value is already supplied, clearly a typo correction, or explicitly approved by the user. - Ask the user if the missing value is a modeling input. Do not guess unknown physical constants or initial conditions unless the user explicitly accepts the assumption. ## Duplicate Definition Symptoms: - A variable is defined more than once. - A variable appears both as an explicit variable and as a model variable. - A table header contains a duplicate name. Repair action: - Keep one definition when the duplicate is accidental. - Rename only when the names refer to distinct concepts. - For duplicate table headers, correct the header and row meanings together. ## Mixed Program Styles Symptoms: - A table appears with differential equations. - A regression command appears with `min:`. - A DEQ derivative appears with NLE root equations. - Linear equations are mixed with nonlinear assignment syntax. Repair action: - Choose one program type. - Remove syntax from other program types. - If the real workflow has multiple stages, generate only one stage at a time. ## Invalid Or Incomplete Table Symptoms: - Duplicate table headers. - A numeric row has too few or too many columns. - Non-numeric table cell. - Multiple table blocks. Repair action: - Keep exactly one table when the selected program type uses a table. - Make every row match the header column count by correcting supplied data, not by inventing missing cells. - Use unique valid variable names in the header. - Keep table data numeric. - Do not invent table columns, cells, or rows to satisfy row/header counts. ## Missing Required Inputs Symptoms: - NLE1 missing bounds. - NLES missing initial guesses. - DEQ missing initial values, final value, or independent-variable range. - REG `nlinfit` missing parameter guesses. - NLP missing guess/bounds lines. - NLP `fit:` missing one data table, measured dependent column, or required table data. Repair action: - Ask for the required input if it is not supplied. - If a heuristic starting value is reasonable, label it as a guess and ask for approval. - Generate final source only after the input is supplied or the assumption is explicitly accepted. ## NLE Repairs For NLE1: - Use one `f(variable)` root equation. - Provide required bounds for the root variable. For NLES: - Use one `f(variable)` root line per nonlinear variable. - Provide one initial guess per nonlinear variable. - Do not invent missing guesses as known data. - If constrained guess syntax such as `>0` or `>=0` is used, follow `spec_nle.md`; do not add or remove constrained-mode directives without preserving the user's intended bounds. For expression evaluation: - Use explicit equations only. - Remove root bounds or guesses unless the selected NLE subtype requires them. ## DEQ Repairs Common repairs: - Keep one derivative notation style. - Provide initial values for differential variables. - Provide a final value or range for the independent variable. - Do not assign an independent-variable range to a differential variable. - Break circular explicit helper equations. Use `spec_deq.md` for exact derivative and initial/final syntax. ## REG Repairs Common repairs: - Keep one table and one command. - Use `polyfit`, `mlinfit`, `nlinfit`, or `integrate`. - For `nlinfit`, use `m(parameter)=guess` for fitted parameter guesses. - Ensure `nlinfit` guesses match fitted model parameters exactly. - Do not use NLP `fit:` syntax for ordinary REG fitting. Use REG for ordinary table-based fitting before considering NLP `fit:`. ## NLP Repairs Common repairs: - Keep exactly one `min:` or NLP `fit:` statement. - Add guess/bounds lines for model variables. - Keep guesses inside bounds. - For NLP `fit:`, ensure exactly one valid table is present. - If NLP `fit:` data are missing, ask instead of fabricating rows. - Convert equality constraints to residual form: `residual = 0`. - Convert inequality constraints to residual form: `residual > 0`. - Do not use `>=`, `<=`, or nonzero inequality right-hand sides. - For a model variable constrained to zero, prefer `x - 0 = 0` instead of bare `x = 0`. Ask for clarification if a constraint cannot be written in supported residual form without changing the model. ## Circular Dependency Symptoms: - A helper equation depends on itself. - Two or more helpers form a dependency loop. Repair action: - Break the loop only by algebraically rewriting the stated model or using a value already provided by the problem. - If breaking the loop requires a new modeling assumption, ask the user. ## Valid Repair Prompt Use this prompt when asking an AI agent to repair source: ```txt The following PolymathPlus source failed precheck. Repair it while preserving the mathematical intent. Do not invent missing inputs. If a required modeling value is missing, ask for it instead of generating final source. Output only the corrected source if repair is possible. Source: Validator messages: ``` ## Final Check Before Solving Before solving, confirm: - The source is one singular supported program type. - Required inputs are present. - There are no unknown variables. - There are no duplicate definitions. - There are no unsupported constraints or mixed syntax. - Precheck passes when a validator is available. --- # PolymathPlus LEQ Specification ## What This Program Type Solves LEQ is the PolymathPlus Linear Equations program type. It solves systems of linear algebraic equations where each equation relates variables with linear terms only. Common rules that always apply: - `#` starts a comment. Comments are ignored by validation. - Blank lines are allowed and ignored. - Validation is line-oriented: each non-comment line is checked as one candidate equation. - The final consistency check is global: total equations must match the number of unique variables across the whole program. - A valid LEQ program must stay in one consistent style. Do not mix LEQ with nonlinear-root, differential-equation, NLP, regression, or table-based program styles. ## User Rules For Writing A Valid LEQ Program ### 1. Keep the program in LEQ style only Allowed style: - Linear equation lines such as `a + 2*b = 10 - 3*a`. - Valid variable names must start with a letter and then use only letters, digits, or underscore. - Valid variable-name examples: `x`, `ab`, `a_1`, `a12`, `abc_34`, `y1_cd_4`. - Do not use built-in function names or conditional keywords as variable names. Examples to avoid include `sin`, `sqrt`, `log`, `if`, `then`, and `else`. - Also avoid variable names that begin with `and` or `or`, because those prefixes are tokenized as logical operators by the validator. Not allowed in the same LEQ program: - Nonlinear root-definition lines such as `f(x)=...`. - Differential-equation lines such as `d(x)/d(t)=...` or `x'=...`. - Data tables using `[` and `]`. - Nonlinear explicit-assignment style, such as an assignment using `sin(...)`, `sqrt(...)`, `/`, `^`, or parentheses. ### 2. Use exactly one `=` per equation line Each active line must contain exactly one equals sign splitting left and right expressions. Both sides of `=` must be non-empty expressions. Invalid examples: ```polymathplus x + y x = y = 3 x = ``` ### 3. Use only LEQ-accepted expression content On each side of `=` use only: - Variable names - Numeric constants, including decimal and scientific notation - Operators: `+`, `-`, `*` Do not use: - `/` - `^` - `(` or `)` - functions such as `sin`, `sqrt`, `log`, or `exp` - comparisons such as `>`, `<`, `>=`, or `<=` - comma decimal notation ### 4. Use coefficient multiplication carefully LEQ accepts both explicit multiplication and coefficient shorthand. Valid examples: ```polymathplus 2*x + 3*y = 12 2x + 3y = 12 2 x + 3 y = 12 -3.5a + 2b = 0 1.2e-3*x + y = 5 ``` Important limits: - Coefficient shorthand is intended for number-to-variable multiplication only. - The validator accepts both compact and spaced coefficient shorthand, such as `2x` and `2 x`. - Variable-to-variable multiplication is nonlinear and invalid. - Parentheses are not allowed, so forms like `2(x+y)` are invalid. - Variable followed by number is invalid, for example `x2` is one variable name, but `x 2` is two adjacent tokens and is invalid. ### 5. Avoid invalid token sequences These patterns are rejected: - Two consecutive operators - Two consecutive numbers - Variable followed by number as a separate token - Variable followed by variable as a separate token - Expression ending with an operator Note: number followed by variable is accepted when it is coefficient shorthand, such as `2x`. ### 6. Keep equations linear A product of two variables is rejected as nonlinear. Invalid pattern: ```polymathplus var * var ``` Invalid example: ```polymathplus b = 0.25*c*c ``` Repair: ```polymathplus b = 0.25*c ``` If the model truly needs products of variables, it is not an LEQ program. Use an NLE or NLP program type instead. ### 7. Match equation count to variable count Across the full LEQ program: - Number of equations must equal number of unique variables found in expressions. If they do not match, the program is rejected. Example invalid structure: ```polymathplus x + y = 4 x - y = 1 z = 2 ``` This has three equations and three variables, so it is structurally OK. This is invalid: ```polymathplus x + y = 4 x - y = 1 z + w = 2 ``` It has three equations but four variables. ### 8. Practical checklist before solve - The program contains at least one linear equation line. - Every active line has exactly one `=`. - Only `+`, `-`, and `*` operators are used. - No `/`, `^`, parentheses, functions, comparisons, or data tables are used. - No nonlinear terms are used, such as `x*y`. - Equation count equals unique-variable count. - The program uses LEQ style only. ## Examples Of Valid LEQ Programs ### Example A: 2 equations, 2 variables, coefficient shorthand ```polymathplus 2x + 3y = 12 4x = 5 + y ``` ### Example B: 5 equations, 5 variables ```polymathplus c + e = 1 3*b - 2*c - 2*d = -2 2*a - 0.27*c - d - 2*e = -1 b = 0.25*c 1.5*a = e ``` ### Example C: Linear material balance with decimal coefficients ```polymathplus .07*D1 + .18*B1 + .15*D2 + .24*B2 = 0.15*70 .04*D1 + .24*B1 + .1*D2 + .65*B2 = 0.25*70 .54*D1 + .42*B1 + .54*D2 + .1*B2 = 0.40*70 .35*D1 + .16*B1 + .21*D2 + .01*B2 = 0.20*70 ``` ### Example D: Scientific notation coefficients ```polymathplus 1.2e-3*x + y = 5 3*x - 2.5e+1*y = 10 ``` ## Invalid Examples And Repairs ### Nonlinear variable product Invalid: ```polymathplus x + y = 10 x*y = 20 ``` Repair by changing the model to a linear form, or use another program type if the variable product is required. ```polymathplus x + y = 10 2*x + 3*y = 20 ``` ### Mixed LEQ and nonlinear assignment Invalid: ```polymathplus x + y = 10 2*x - y = 4 rate = sin(x) ``` Repair by keeping only LEQ lines, or use NLE if nonlinear expressions are required. ```polymathplus x + y = 10 2*x - y = 4 ``` ### Equation count does not match variable count Invalid: ```polymathplus x + y = 4 x - y = 1 z + w = 2 ``` Repair by adding/removing equations or variables so the counts match. ```polymathplus x + y = 4 x - y = 1 z = 2 ``` ### Unsupported operator Invalid: ```polymathplus x/2 + y = 10 x - y = 4 ``` Repair by rewriting division as multiplication by a numeric coefficient. ```polymathplus 0.5*x + y = 10 x - y = 4 ``` ## Verification Notes This hardened repo-local copy was checked against the LEQ behavior in: ```txt C:\dev\js\solver_precheck\solver_precheck.js C:\dev\js\solver_precheck\solver_precheckTests.js ``` The current examples were selected or adapted from the test corpus and validator behavior. Test-only comments were removed, and example variable names/comments were adjusted for documentation use. --- # PolymathPlus NLE Specification ## What This Program Type Solves NLE is the PolymathPlus nonlinear algebraic program family. It covers expression evaluation and nonlinear root solving. This specification covers: - `NLE0`: explicit-equation and expression-evaluation mode, with no root-solving. - `NLE1`: one nonlinear root equation. - `NLES`: two or more simultaneous nonlinear root equations. Common rules that always apply: - `#` starts a comment. Comments are ignored by validation. - Blank lines are allowed and ignored. - Variable names must start with a letter and then use only letters, digits, or underscore. - Do not use built-in function names or conditional keywords as variable names. Examples to avoid include `sin`, `sqrt`, `log`, `if`, `then`, and `else`. - Also avoid variable names that begin with `and` or `or`, because those prefixes are tokenized as logical operators by the validator. - Keep one consistent program style. Do not mix NLE with DEQ, LEQ, NLP, regression, or table-based program formats. ## User Rules For Writing A Valid NLE Program ### 1. Choose the correct NLE subtype Use `NLE0` when the program only evaluates explicit equations and optional anonymous expressions: ```polymathplus a = 1 b = 4 x = a + b^2 x + 2 ``` Use `NLE1` when solving one nonlinear root equation: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` Use `NLES` when solving two or more nonlinear root equations: ```polymathplus f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 y(0) = 0.5 ``` ### 2. Root-line rules Root lines use this format: ```polymathplus f(variable) = expression ``` Rules: - The variable inside `f(...)` is the nonlinear variable to solve for. - Write the right-hand side as a residual expression that should become zero. - Do not add a second `= 0` at the end of the root line. - Do not define the same nonlinear variable more than once. - Root expressions must be valid math expressions. - Multiplication may be explicit or implicit, for example `2*x^2` or `2x^2`. Example conversion: If the mathematical equation is: ```polymathplus 2x^2 - sin(1/x) = 0.5 ``` write it as: ```polymathplus f(x) = 2*x^2 - sin(1/x) - 0.5 ``` Invalid: ```polymathplus f(x) = x^2 - 4 = 0 x(min) = 0 x(max) = 3 ``` Repair: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` ### 3. Explicit-equation rules Explicit equations use this format: ```polymathplus variable = expression ``` Rules: - Explicit equations are allowed in all NLE subtypes. - Use explicit equations to simplify long formulas or reuse repeated sub-expressions. - Explicit variable names must be unique. - Explicit variables must not be circular or self-referencing. - An explicit variable cannot use the same name as a nonlinear root variable. Valid: ```polymathplus f(x) = g - 0.5 g = sin(x) + x^2 x(min) = 0 x(max) = 1 ``` Invalid direct self-reference: ```polymathplus f(x) = a - 2 a = a + 1 x(min) = 0 x(max) = 3 ``` Invalid circular reference: ```polymathplus f(x) = a - 2 a = b + 1 b = a + 1 x(min) = 0 x(max) = 3 ``` Invalid overlap between explicit and nonlinear variable: ```polymathplus f(x) = g x = 2 g = x + 1 x(min) = 0 x(max) = 3 ``` Repair by renaming or removing the overlapping explicit variable: ```polymathplus f(x) = g g = x + 1 x(min) = 0 x(max) = 3 ``` ### 4. Anonymous-expression rules Anonymous expressions are expressions without a left-hand variable assignment. Rules: - `NLE0` allows anonymous expressions when they are syntactically valid and use variables defined by explicit assignments in the same program. For validation, the explicit assignment may appear before or after the anonymous expression; for readability, define variables before using them. - `NLE1` and `NLES` do not allow anonymous expressions. Valid `NLE0`: ```polymathplus a = 1 b = 4 x = a + b^2 x + 2 ``` Invalid `NLE1`: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 x + 2 ``` Repair: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` ### 5. Initial-guess and boundary rules For `NLE0`: - Do not use `x(0)=...`, `x(min)=...`, `x(max)=...`, or `x(f)=...` lines. For `NLE1`: - Provide exactly one minimum boundary: `x(min)=number`. - Provide exactly one maximum boundary: `x(max)=number`. - Do not use `x(0)=...` initial-guess lines. - Recommended: use the same variable name as the root line, for example `x(min)` and `x(max)` for `f(x)`. - Current precheck behavior: it requires exactly one numeric `min` boundary and one numeric `max` boundary, and checks that `min < max`; it does not currently enforce that the boundary variable name matches the root variable name. - Minimum must be strictly less than maximum. - Boundary values must be numeric literals, not expressions. Invalid `NLE1` using an initial guess: ```polymathplus f(x) = x^2 - 4 x(0) = 1 ``` Repair: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` Invalid `NLE1` boundary expression: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 2 + 1 ``` Repair: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` Current precheck accepts this, but it is not recommended because the boundary variable names do not match the root variable: ```polymathplus f(x) = x^2 - 4 y(min) = 0 y(max) = 3 ``` Recommended form: ```polymathplus f(x) = x^2 - 4 x(min) = 0 x(max) = 3 ``` For `NLES`: - Do not use `x(min)=...` or `x(max)=...` lines. - Provide one initial guess per nonlinear variable: `x(0)=number`. - Each initial-guess variable must match a variable defined in a root line. - Do not provide guesses for variables that do not have a matching root line. - Initial-guess values must be numeric literals unless constrained mode is enabled. Invalid `NLES` with a missing initial guess: ```polymathplus f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 ``` Repair: ```polymathplus f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 y(0) = 0.5 ``` ### 6. Constrained initial guesses Constrained initial guesses are allowed only for `NLES` when the constrained method directive is present: ```polymathplus #@ NLE_SOLUTION_METHOD_INDEX = 3 ``` For precheck, this directive must be on its own comment line. Do not add trailing text after `3` on the same line. Allowed constrained guess forms: ```polymathplus x(0) = 0.5 >0 y(0) = 0.35 >=0 ``` Invalid without constrained mode: ```polymathplus f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 >0 y(0) = 0.5 ``` Repair: ```polymathplus #@ NLE_SOLUTION_METHOD_INDEX = 3 f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 >0 y(0) = 0.5 ``` Invalid because the constrained directive has trailing text on the same line: ```polymathplus #@ NLE_SOLUTION_METHOD_INDEX = 3 # constrained method f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 >0 y(0) = 0.5 ``` Repair by keeping the directive line exact and moving comments to another line: ```polymathplus # constrained method #@ NLE_SOLUTION_METHOD_INDEX = 3 f(x) = x + y - 1 f(y) = x - y x(0) = 0.5 >0 y(0) = 0.5 ``` Optional solver method hint: ```polymathplus #@ NLE_SOLUTION_METHOD_INDEX = 1 ``` Known method index values used by PolymathPlus: - `0`: Fast-Newton - `1`: Safe-Newton - `2`: Safe-Broydn - `3`: Constrained Default when omitted: `1` (`Safe-Newton`). Precheck note: - The precheck specifically uses the `3` directive to allow constrained initial-guess syntax such as `>0` and `>=0`. - Other method values are treated as comment metadata by precheck and are not validated as supported or unsupported values. ### 7. Unknown-variable rules Every variable used inside root expressions and explicit expressions must be defined as one of: - a nonlinear variable from a root line - an explicit variable from an assignment line For `NLE0`, anonymous expressions may use only variables defined by explicit assignments in the same program. Validation is order-independent, but defining variables before anonymous expressions is clearer for users and LLMs. Invalid: ```polymathplus f(x) = x + y - 1 x(min) = 0 x(max) = 2 ``` Repair: ```polymathplus f(x) = x + y - 1 y = 0.5 x(min) = 0 x(max) = 2 ``` ## Practical Checklist Before Solve - Choose exactly one NLE style: `NLE0`, `NLE1`, or `NLES`. - Use `f(variable)=expression` only for root equations. - Write root equations as residuals; do not end with a second `=0`. - Keep root variables unique. - Keep explicit variables unique and non-circular. - Do not reuse a root variable name as an explicit variable name. - Use anonymous expressions only in `NLE0`. - For `NLE1`, provide exactly one matching `min` and `max` boundary. - For `NLES`, provide exactly one matching initial guess per root variable. - Use constrained initial guesses only with `#@ NLE_SOLUTION_METHOD_INDEX = 3`. - Make sure every referenced variable is defined. ## Examples Of Valid NLE Programs ### Example A: `NLE0` explicit equations and anonymous expression ```polymathplus a = 1 b = 4 x = a + b^2 x + 2 ``` ### Example B: `NLE1` one root equation with helper expression ```polymathplus f(x) = t + 4*x^2 - 1620 t = x*log(x/2) x(min) = 0.1 x(max) = 100 ``` ### Example C: `NLES` nonlinear system ```polymathplus f(c) = 3.8907 - ln(6*c) - a f(a) = a + b - c b = 5*a - 3 c(0) = 2 a(0) = 2 ``` ### Example D: `NLES` with constrained initial guesses ```polymathplus #@ NLE_SOLUTION_METHOD_INDEX = 3 f(x1) = x1 + x2 - 1 f(x2) = x1^2 + x2 - 0.75 x1(0) = 0.35 >=0 x2(0) = 0.5 >0 ``` ## Verification Notes This hardened repo-local copy was checked against NLE behavior in: ```txt C:\dev\js\solver_precheck\solver_precheck.js C:\dev\js\solver_precheck\solver_precheckTests.js ``` The examples were selected or adapted from the test corpus and validator behavior. Test-only comments were removed, and example variable names/comments were adjusted for documentation use. --- # PolymathPlus DEQ Specification ## What This Program Type Solves DEQ is the PolymathPlus differential-equation program type. It solves initial-value ordinary differential equations, including systems of ODEs, with optional explicit helper equations. Common rules that always apply: - `#` starts a comment. Comments are ignored by validation. - Blank lines are allowed and ignored. - Variable names must start with a letter and then use only letters, digits, or underscore. - Avoid built-in function names or conditional keywords as variable names. Examples to avoid include `sin`, `sqrt`, `log`, `if`, `then`, and `else`. The left side of some DEQ lines may still pass precheck with these names, but expression use will be tokenized as functions or conditional keywords. - Also avoid variable names that begin with `and` or `or`, because those prefixes are tokenized as logical operators by the validator when used in expressions. - Keep one consistent program style. Do not mix DEQ with LEQ, NLE, NLP, regression, or table-based program formats. ## User Rules For Writing A Valid DEQ Program ### 1. Use a supported derivative-line format Supported derivative-line formats: ```polymathplus d(x)/d(t) = expression dx/dt = expression x' = expression ``` Rules: - The right-hand side must be a valid math expression. - Each differential variable can be defined only once. - If you use `d()/d()` notation, the derivative line must be fully parenthesized or fully compact. - Mixed derivative notation such as `d(x)/dt` is invalid. - Prime notation such as `x' = ...` is accepted, but the independent variable is inferred from the independent-variable final/range definition. With prime notation, provide exactly one independent-variable range/final definition such as `t|0:3` or `t(0)=0` plus `t(f)=3`. - Do not use `var|start:end` for a differential variable. The `|start:end` form belongs to the independent variable only. Invalid mixed derivative notation: ```polymathplus d(T)/dt = -k*T k = 1 T(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(T)/d(t) = -k*T k = 1 T(0) = 1 t(0) = 0 t(f) = 2 ``` ### 2. Use one independent variable All derivative lines must use the same independent variable. Valid: ```polymathplus d(A)/d(t) = -k*A d(B)/d(t) = k*A A(0) = 1 B(0) = 0 t(0) = 0 t(f) = 5 ``` Invalid mixed independent variables: ```polymathplus d(A)/d(t) = -A d(B)/d(x) = -B A(0) = 1 B(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A d(B)/d(t) = -B A(0) = 1 B(0) = 1 t(0) = 0 t(f) = 2 ``` ### 3. Explicit-equation rules Explicit equations use this format: ```polymathplus variable = expression ``` Rules: - Explicit equations are allowed in DEQ programs. - Use explicit equations to simplify long derivative formulas or reuse repeated terms. - Explicit variable names must be unique. - Explicit variables must not be circular or self-referencing. - An explicit variable cannot use the same name as a differential variable. - The independent variable cannot also be an explicit variable. Valid helper equations: ```polymathplus q1 = W*Cp*(T0-T1)+UA*(Tsteam-T1) q2 = W*Cp*(T1-T2)+UA*(Tsteam-T2) d(T1)/d(t) = q1/(M*Cp) d(T2)/d(t) = q2/(M*Cp) T1(0) = 20 T2(0) = 20 t(0) = 0 t(f) = 200 ``` Invalid explicit/differential overlap: ```polymathplus d(A)/d(t) = -A A = 2 A(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` Invalid independent variable as explicit variable: ```polymathplus d(A)/d(t) = -A t = 0 A(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` ### 4. Initial-value rules Every differential variable needs exactly one initial value. Supported initial-value formats: ```polymathplus x(0) = number x|number ``` Rules: - Initial values must be numeric literals, not expressions. - Do not define the same initial value more than once for the same variable. - Do not provide initial values for unknown variables. Invalid duplicate initial value: ```polymathplus d(A)/d(t) = -A A(0) = 1 A|2 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` Invalid initial value expression: ```polymathplus d(A)/d(t) = -A A(0) = 1 + 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 2 t(0) = 0 t(f) = 2 ``` ### 5. Independent-variable initial/final/range rules The independent variable must have an initial value and a final value. The final value must be greater than the initial value. Supported formats: ```polymathplus t(0) = number t(f) = number t|start:end ``` Rules: - Only the independent variable can use `(f)` or `|start:end`. - Final/range values must be numeric literals, not expressions. - Keep only one final/range definition for the independent variable. - Do not assign a final value or range to a differential variable. Valid range syntax: ```polymathplus A' = -k*A k = 1 A|1 t|0:3 ``` Invalid prime/range usage: ```polymathplus A' = -k*A k = 1 A|1:3 t|0:3 ``` Repair: ```polymathplus A' = -k*A k = 1 A|1 t|0:3 ``` Invalid final value on a differential variable: ```polymathplus d(A)/d(t) = -A A(0) = 1 A(f) = 2 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` Invalid duplicate final/range definition: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 t|0:3 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` Invalid final value not greater than initial value: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 2 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -A A(0) = 1 t(0) = 0 t(f) = 2 ``` ### 6. Unknown-variable and role-consistency rules Every variable used in derivative or explicit expressions must be one of: - a differential variable - an explicit variable - the independent variable Invalid unknown variable: ```polymathplus d(A)/d(t) = -k*A A(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -k*A k = 0.5 A(0) = 1 t(0) = 0 t(f) = 2 ``` Invalid circular explicit definitions: ```polymathplus d(A)/d(t) = -k*A k = q + 1 q = k + 1 A(0) = 1 t(0) = 0 t(f) = 2 ``` Repair: ```polymathplus d(A)/d(t) = -k*A k = 0.5 A(0) = 1 t(0) = 0 t(f) = 2 ``` ### 7. Solver method metadata Optional DEQ solver method hint: ```polymathplus #@DEQ_SOLUTION_METHOD_INDEX = 0 ``` Known solver/runtime method index values used by PolymathPlus: - `0`: RKF45 - `1`: RKF56 - `2`: BS - `3`: Stiff - `4`: StiffBS Runtime default when omitted: `0` (`RKF45`). Precheck note: - The precheck treats this line as comment/directive metadata. - The precheck does not currently validate the method index as supported or unsupported. ## Practical Checklist Before Solve - At least one valid derivative line exists. - All derivative lines use one independent variable. - Every differential variable has exactly one numeric initial value. - The independent variable has a numeric initial value. - The independent variable has exactly one numeric final/range definition. - The final value is strictly greater than the initial value. - Explicit variables are unique and non-circular. - No explicit variable overlaps a differential variable. - The independent variable is not also explicit or differential. - No unknown variables remain in derivative or explicit expressions. ## Examples Of Valid DEQ Programs ### Example A: One ODE using fully parenthesized derivative notation ```polymathplus d(T)/d(t) = -k*(T - Ta) k = 0.15 Ta = 25 T(0) = 120 t(0) = 0 t(f) = 20 ``` ### Example B: Three ODEs using prime notation and pipe syntax ```polymathplus A' = -k1*A B' = k1*A - k2*B C' = k2*B k1 = 1 k2 = 2 A|1 B|0 C|0 t|0:3 ``` ### Example C: Two ODEs using compact derivative notation ```polymathplus dT1/dt = (W*Cp*(T0-T1)+UA*(Tsteam-T1))/(M*Cp) dT2/dt = (W*Cp*(T1-T2)+UA*(Tsteam-T2))/(M*Cp) W = 100 Cp = 2.0 T0 = 20 UA = 10 Tsteam = 250 M = 1000 T1(0) = 20 T2(0) = 20 t(0) = 0 t(f) = 200 ``` ### Example D: Engineering-style ODE system with an explicit rate ```polymathplus d(CA)/d(t) = -rA d(CB)/d(t) = rA rA = k*CA k = 0.25 CA(0) = 1 CB(0) = 0 t(0) = 0 t(f) = 10 ``` ## Verification Notes This hardened repo-local copy was checked against DEQ behavior in: ```polymathplus C:\dev\js\solver_precheck\solver_precheck.js C:\dev\js\solver_precheck\solver_precheckTests.js ``` The examples were selected or adapted from the test corpus and validator behavior. Test-only comments were removed, and example variable names/comments were adjusted for documentation use. --- # PolymathPlus Regression Specification ## What This Program Type Solves Regression programs in PolymathPlus fit models to tabular data or compute numerical integrals from tabular data. This specification covers: - Polynomial regression: `polyfit`, including linear regression when order is `1` - Multi-linear regression: `mlinfit` - Nonlinear regression: `nlinfit` - Numerical integration from table data: `integrate` Common rules that always apply: - `#` starts a comment. Comments are ignored by validation. - Blank lines are allowed and ignored. - A regression program must contain exactly one data table block and exactly one regression command. - The regression command must be one of: `polyfit`, `mlinfit`, `nlinfit`, or `integrate`. - Variable names must start with a letter and then use only letters, digits, or underscore. - Avoid built-in function names or conditional keywords as variable names. Examples to avoid include `sin`, `sqrt`, `log`, `if`, `then`, and `else`. - Keep one consistent program style. Do not mix regression with DEQ, LEQ, NLE, NLP, or table-free program formats. ## User Rules For Writing A Valid Regression Program ### 1. Required structure Every regression program must contain: - One data table block enclosed by `[` and `]` - One regression command - Optional explicit equations outside the table - Optional nonlinear-regression initial guesses, only for `nlinfit` Additional structure rules: - Exactly one table start line (`[`) and one table end line (`]`) are allowed. - More than one data table is invalid. - More than one regression command is invalid. - Unknown lines outside the table are invalid. Invalid multiple commands: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] polyfit x y 2 integrate y(x) 1 5 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] polyfit x y 2 ``` ### 2. Data table rules Table format: - First non-comment, non-blank line inside `[` ... `]` is the header. - Header tokens are variable names separated by spaces. - Header variable names must be unique. - Each numeric row must have exactly the same number of columns as the header. - Numeric table cells must be valid numeric literals, including decimal and scientific notation. - Comments and blank lines inside the table are ignored. - Table cells are separated by one or more spaces. Valid table: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] ``` Invalid row with missing column: ```polymathplus [ x y 1 2 2 3 4 4 5 5 6 ] polyfit x y 2 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] polyfit x y 2 ``` Invalid duplicate header variable: ```polymathplus [ x x 1 2 2 3 3 4 4 5 5 6 ] polyfit x x 2 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] polyfit x y 2 ``` ### 3. Explicit-equation rules Explicit equations are optional helper definitions and are allowed in all regression subtypes. Rules: - Explicit variable names must be unique. - Explicit expressions must be valid math expressions. - Circular and self-referencing explicit dependencies are invalid. - For `nlinfit`, explicit variables may depend only on table variables or other explicit variables. - For `nlinfit`, explicit variables must not depend on fitted model-parameter variables. Invalid circular explicit definitions: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] a = b + 1 b = a + 1 polyfit x y 2 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] a = x + 1 polyfit x y 2 ``` ## Command Rules ### 4. Polynomial and linear regression: `polyfit` Syntax: ```txt polyfit x y order polyfit x y order origin ``` Rules: - `x` and `y` must be table variables or explicit variables. - Recommended: write `order` as an integer. - Current precheck behavior: decimal-looking values such as `2.5` can be accepted and parsed as `2`; avoid this because it is ambiguous. - `order = 1` is classified as linear regression. - Higher orders are classified as polynomial regression. - The polynomial order must not exceed available numeric data rows. - Optional trailing `origin` is allowed. Valid: ```polymathplus [ Time BOD 1 0.6 2 0.7 4 1.5 6 1.9 8 2.1 10 2.6 ] polyfit Time BOD 2 ``` Invalid order too high for the data: ```polymathplus [ x y 1 2 2 3 ] polyfit x y 4 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] polyfit x y 4 ``` ### 5. Multi-linear regression: `mlinfit` Syntax: ```txt mlinfit x1 x2 ... y mlinfit x1 x2 ... y origin ``` Rules: - List predictor variables first and the dependent variable last. - Optional trailing `origin` is allowed. - All listed variables must be table variables or explicit variables. - Table row count must be large enough for the selected model size. - Recommended: use at least one predictor variable and one dependent variable. - Current precheck behavior: command variables are counted as unique variables, so duplicated variable names are not counted twice. Some underspecified commands may pass precheck if the listed variables are known; avoid them because they do not describe a useful multi-linear model. - Validator row-count rule: if `k` is the number of unique listed variables after `mlinfit`, including `y`, then: - without `origin`: rows must be at least `k + 1` - with `origin`: rows must be at least `k + 2` Valid: ```polymathplus [ y x1 x2 293 1.61 851 230 15.5 820 172 22 1058 91 45 1201 125 33 1357 125 40 1115 ] mlinfit x1 x2 y ``` Invalid too few rows: ```polymathplus [ y x1 x2 293 1.61 851 230 15.5 820 172 22 1058 ] mlinfit x1 x2 y ``` Repair: ```polymathplus [ y x1 x2 293 1.61 851 230 15.5 820 172 22 1058 91 45 1201 ] mlinfit x1 x2 y ``` ### 6. Nonlinear regression: `nlinfit` Syntax: ```polymathplus nlinfit y = expression m(a) = 2 m(b) = 1 ``` Rules: - Left-hand side must be `nlinfit dependentVariable = expression`. - The dependent variable must be a table variable or explicit variable. - The model expression must be valid math syntax. - Recommended: the model expression should include at least one independent variable from table data or an explicit helper based on table data. - Current precheck behavior: it treats explicit variables as available independent variables even if they are constants, so a model can pass precheck while being statistically unhelpful. For modeling quality, make the fitted expression depend on table data. - Fitted model parameters are variables used in the model expression that are not table variables and not explicit variables. - At least one fitted model parameter must exist. - Initial guesses use `m(parameter)=number`. - Initial guesses are required for fitted model parameters. - Initial-guess variables must match fitted model parameters exactly. - Extra, missing, or misspelled initial guesses are invalid. - For `nlinfit`, explicit variables must not depend on fitted model parameters. Valid: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 ``` Invalid missing initial guess: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 ``` Repair: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 ``` Invalid extra initial guess: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 m(c)=1 ``` Repair: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 ``` Invalid because there is no fitted parameter: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = 2*x/(1 + x) ``` Repair: ```polymathplus [ x y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*x/(b + x) m(a)=2 m(b)=1 ``` Invalid explicit helper depending on fitted model parameter: ```polymathplus [ w y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] scale = a + 1 nlinfit y = scale*w/(b+w) m(a)=2 m(b)=1 ``` Repair: ```polymathplus [ w y 0.5 1.255 0.387 1.25 0.24 1.189 0.136 1.124 0.04 0.783 0.011 0.402 ] nlinfit y = a*w/(b+w) m(a)=2 m(b)=1 ``` Optional nonlinear-regression solver metadata: ```polymathplus #@NLR_SOLUTION_METHOD_INDEX = 1 ``` Known runtime values: - `0`: MRQMIN - `1`: L-M - `2`: GaussNewton Precheck note: precheck treats this directive as comment metadata and does not validate the method index. ### 7. Numerical integration: `integrate` Syntax: ```txt integrate y(x) x0 xf integrate y(x) x0 xf sections integrate y(x) x0 xf sections method ``` Rules: - `y` and `x` must be table variables or explicit variables. - `x0` and `xf` must be valid numeric values. - Decimal comma is accepted in command bounds by validator numeric parsing, for example `0,03`. - Optional `sections` must be an integer and must be `<= 2000`. - Optional `method` must be one of: `akm`, `ccs`, or `lin`. - Integration requires at least 5 numeric table rows. Valid: ```polymathplus [ t C F 0 0 0 0.4 32900000 0.03294052 1 62200000 0.09521712 2 81200000 0.1435766 3 83100000 0.16450234 4 78500000 0.16179901 ] integrate F(t) 0 4 120 ``` Invalid method: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) 0.03 0.4 120 ccm ``` Repair: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) 0.03 0.4 120 ccs ``` Invalid integration bound: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) start 0.4 120 ccs ``` Repair: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) 0.03 0.4 120 ccs ``` Invalid too many sections: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) 0.03 0.4 2001 ccs ``` Repair: ```polymathplus [ x y 0.03 0.1 0.1 0.2 0.2 0.5 0.3 0.8 0.4 1.1 ] integrate y(x) 0.03 0.4 120 ccs ``` Invalid too few rows: ```polymathplus [ x y 1 2 2 3 3 4 4 5 ] integrate y(x) 1 4 ``` Repair: ```polymathplus [ x y 1 2 2 3 3 4 4 5 5 6 ] integrate y(x) 1 5 ``` ## Practical Checklist Before Solve - Exactly one table block is present and correctly enclosed by `[` and `]`. - Header variable names are valid and unique. - Every numeric row matches the header column count. - Exactly one regression command is present. - Command syntax matches the selected subtype. - All required variables are known from the table or explicit equations, except fitted parameters in `nlinfit`. - Explicit variables are unique, valid, and non-circular. - For `nlinfit`, model parameter guesses are numeric and match fitted parameters exactly. - For `integrate`, table has at least 5 rows and optional method/sections are valid. ## Verification Notes This hardened repo-local copy was checked against regression behavior in: ```txt C:\dev\js\solver_precheck\solver_precheck.js C:\dev\js\solver_precheck\solver_precheckTests.js ``` The examples were selected or adapted from the test corpus and validator behavior. Test-only comments were removed, and example variable names/comments were adjusted for documentation use. --- # PolymathPlus NLP Specification ## What This Program Type Solves NLP programs in PolymathPlus solve nonlinear optimization problems. This specification covers: - Non-LSQ optimization: table-free programs with `min:` - LSQ optimization: table-based least-squares programs with `fit:` - Optional explicit helper equations - Optional equality and inequality constraints - Initial guesses and lower/upper bounds for model variables Primary documentation objective: Help students and engineers describe a nonlinear optimization or constrained fitting problem in natural language, then have an AI generate valid PolymathPlus NLP source. Common rules that always apply: - `#` starts a comment. Comments are ignored by validation. - Blank lines are allowed and ignored. - Variable names must start with a letter and then use only letters, digits, or underscore. - Avoid built-in function names or conditional keywords as variable names. Examples to avoid include `sin`, `sqrt`, `log`, `if`, `then`, and `else`. - Keep one consistent program style. Do not mix NLP with DEQ, LEQ, NLE, or regression command formats. - A program must contain exactly one main statement: either `min:` or `fit:`. ### Math expression syntax NLP expressions use the shared PolymathPlus expression checker. Supported expression features include: - numeric literals, including decimal and scientific notation - arithmetic operators `+`, `-`, `*`, `/`, and `^` - parentheses - built-in math functions such as `sin`, `cos`, `tan`, `sqrt`, `log`, `ln`, `exp`, and `arctan` - conditional expressions using `if ... then ... else ...` - comparison/logical operators inside conditional expressions Current precheck behavior: - Some implicit multiplication forms are accepted, including `2x`, `2 x`, and adjacent variable/function/parenthesis forms. - For generated source, prefer explicit `*` because it is clearer and less likely to be misread by users or future tooling. ## User Rules For Writing A Valid NLP Program ### 1. Choose the NLP style Use `min:` for nonlinear optimization without a data table: ```txt min: objective_expression ``` Use `fit:` for least-squares parameter estimation against a data table: ```txt fit: measured_variable = model_expression ``` Current precheck behavior: - `fit:` without a table is invalid. - If no recognized main statement is present, table presence affects the missing-statement message: with a table, precheck asks for `fit:`; without a table, it asks for `min:`. - Current precheck can accept a table-plus-`min:` program when the variables resolve. Treat this as validator leniency, not recommended modeling syntax. Recommended modeling practice: - Use `min:` for objective functions written directly by the modeler. - Use `fit:` when the objective is the sum of squared residuals between measured table values and a model expression. Not recommended table with `min:`: ```polymathplus [ x y 1 2 2 4 3 6 ] min: a*x a| 1 0 10 ``` Recommended LSQ form: ```polymathplus [ x y 1 2 2 4 3 6 ] fit: y = a*x a| 1 0 10 ``` Invalid `fit:` without a table: ```polymathplus fit: y = a*x a| 1 0 10 x| 1 0 5 ``` Repair: ```polymathplus [ x y 1 2 2 4 3 6 ] fit: y = a*x a| 1 0 10 ``` ### 2. Main statement rules Non-LSQ syntax: ```txt min: expression ``` LSQ syntax: ```txt fit: y = expression ``` Rules: - Exactly one main statement is allowed. - The `min:` expression must be a valid math expression. - The `fit:` right-hand expression must be a valid math expression. - In `fit: y = expression`, the dependent variable `y` must not appear in the right-hand expression. - Variables used in the main statement must be known from the table, explicit equations, or guess/bounds lines. Invalid duplicate main statements: ```polymathplus min: x^2 + y^2 min: (x - 1)^2 + (y - 1)^2 x| 0 -5 5 y| 0 -5 5 ``` Repair: ```polymathplus min: x^2 + y^2 x| 0 -5 5 y| 0 -5 5 ``` Invalid `fit:` dependent variable on the right side: ```polymathplus [ x y 1 2 2 4 3 8 4 16 ] fit: y = a*x + y a| 1 0 10 ``` Repair: ```polymathplus [ x y 1 2 2 4 3 8 4 16 ] fit: y = a*x a| 1 0 10 ``` ### 3. What LSQ minimizes In NLP, `fit:` means least-squares parameter estimation. For a program of the form: ```txt fit: y = f(x, parameters) ``` with table rows `(x_i, y_i)`, the intended modeling pattern is that the solver uses the model parameters as decision variables and minimizes: ```txt sum_i (y_i - f(x_i, parameters))^2 ``` If constraints are included, the problem becomes constrained least squares: - Objective: minimize squared residuals. - Constraints: satisfy `= 0` constraints, `> 0` constraints, and variable bounds. Recommended modeling practice: - The `fit:` left-hand variable should be a measured table column. - Include at least one fitted model parameter with a guess/bounds line. Current precheck behavior: - The `fit:` left-hand variable only has to be known; current precheck can accept it as a table variable, explicit variable, or guess/bounds variable. - Current NLP precheck can accept a `fit:` expression with no fitted parameters. Treat this as validator leniency, not useful modeling syntax. ### 4. Data table rules for `fit:` The LSQ style requires one table block enclosed by `[` and `]`. Table format: - First non-comment, non-blank line inside the table is the header. - Header tokens are variable names separated by spaces. - Header variable names must be unique. - Each numeric row must have exactly the same number of columns as the header. - Numeric cells must be valid numeric literals, including decimal and scientific notation. - Comments and blank lines inside the table are ignored. - Only one table block is allowed. Recommended modeling practice: - Include at least one numeric data row. - For `fit: y = expression`, make `y` a table header variable. Current precheck behavior: - NLP precheck may accept a header-only table. Treat this as validator leniency; it is not a meaningful fit dataset. Valid LSQ table: ```polymathplus [ x y 1.309 2.138 1.471 3.421 1.490 3.597 1.565 4.340 1.611 4.882 1.680 5.660 ] fit: y = b1*x^b2 b1| 0.7 0 2 b2| 4.0 0 10 ``` Invalid row width: ```polymathplus [ x y 1.309 2.138 1.471 1.490 3.597 ] fit: y = b1*x^b2 b1| 0.7 0 2 b2| 4.0 0 10 ``` Repair: ```polymathplus [ x y 1.309 2.138 1.471 3.421 1.490 3.597 ] fit: y = b1*x^b2 b1| 0.7 0 2 b2| 4.0 0 10 ``` Invalid duplicate header variable: ```polymathplus [ t y t 0 1 0 1 2 1 2 4 2 ] fit: y = a*exp(b*t) a| 1 0 10 b| 0.5 0 3 ``` Repair: ```polymathplus [ t y 0 1 1 2 2 4 ] fit: y = a*exp(b*t) a| 1 0 10 b| 0.5 0 3 ``` ### 5. Explicit variable rules Explicit equations define helper variables: ```txt helper = expression ``` Rules: - Explicit variable names must be unique. - Explicit expressions must be valid math expressions. - Circular and self-referencing explicit definitions are invalid. - A variable cannot be both an explicit variable and a model variable with a guess/bounds line. - Variables used in explicit expressions must be known from the table, other explicit variables, or guess/bounds lines. - Explicit variables may appear before or after the main statement, as long as the dependency graph is valid. Valid helper equations: ```polymathplus pi_val = 4*arctan(1) volume = 100 min: pi_val*r^2*h pi_val*r^2*h - volume = 0 r| 2 0.1 10 h| 5 0.1 20 ``` Invalid circular helpers: ```polymathplus min: x^2 + a a = b + 1 b = a + 1 x| 1 -5 5 ``` Repair: ```polymathplus min: x^2 + a a = b + 1 b = 2 x| 1 -5 5 ``` Invalid explicit/model overlap: ```polymathplus min: x^2 + scale scale = 2 scale| 1 0 10 x| 1 -5 5 ``` Repair: ```polymathplus min: x^2 + scale scale = 2 x| 1 -5 5 ``` ### 6. Initial guess and bound rules NLP model variables are defined using pipe syntax: ```txt var| guess lower_bound upper_bound ``` Rules: - Each model variable can appear only once. - `guess`, `lower_bound`, and `upper_bound` must be numeric literals. - Bounds must satisfy `lower_bound <= upper_bound`. - The initial guess must satisfy `lower_bound <= guess <= upper_bound`. - A guess/bounds variable must be used in the main statement, an explicit expression, or a constraint. - A variable used in the main statement must be defined as a table variable, explicit variable, or model variable. Current precheck behavior: - The accepted guess/bounds pattern is lenient about trailing text after the three numbers. For generated source, write only `var| guess lower_bound upper_bound`. Valid: ```polymathplus min: (x - 2)^2 + (y - 3)^2 x| 1.5 0 10 y| 2.5 0 10 ``` Invalid missing guess for `x`: ```polymathplus min: (x - 2)^2 + (y - 3)^2 y| 2.5 0 10 ``` Repair: ```polymathplus min: (x - 2)^2 + (y - 3)^2 x| 1.5 0 10 y| 2.5 0 10 ``` Invalid duplicate guess: ```polymathplus min: x^2 + y^2 x| 1 -5 5 x| 2 -5 5 y| 1 -5 5 ``` Repair: ```polymathplus min: x^2 + y^2 x| 1 -5 5 y| 1 -5 5 ``` Invalid bound order: ```polymathplus min: (T - 350)^2 T| 340 900 150 ``` Repair: ```polymathplus min: (T - 350)^2 T| 340 150 900 ``` Invalid unused model variable: ```polymathplus min: x^2 x| 1 -5 5 y| 1 -5 5 ``` Repair: ```polymathplus min: x^2 x| 1 -5 5 ``` ### 7. Constraint rules Allowed constraint formats: ```txt expression = 0 expression > 0 ``` Rules: - Equality constraints must be written as `expression = 0`. - Inequality constraints must be written as `expression > 0`. - `>=` and `<=` are not supported by NLP precheck. - Inequality right-hand side must be exactly `0`. - To express `a <= b`, write `b - a > 0`. - To express `a >= b`, write `a - b > 0`. - Constraint expressions may use known variables only. - If constraining a model variable to equal zero, avoid a bare line like `x = 0`; precheck reads that as an explicit assignment before constraint parsing. Write `x - 0 = 0`. Valid constrained optimization: ```polymathplus min: (x - 1)^2 + (y - 1)^2 x + y - 1 = 0 1.5 - (x^2 + y^2) > 0 x| 0.5 -2 2 y| 0.5 -2 2 ``` Invalid unsupported `>=`: ```polymathplus min: (x - 1)^2 + (y - 1)^2 x + y >= 1 x| 0.5 -2 2 y| 0.5 -2 2 ``` Repair: ```polymathplus min: (x - 1)^2 + (y - 1)^2 x + y - 1 > 0 x| 0.5 -2 2 y| 0.5 -2 2 ``` Invalid nonzero inequality right side: ```polymathplus min: (x - 1)^2 + (y - 1)^2 1.5 - (x^2 + y^2) > 3 x| 0.5 -2 2 y| 0.5 -2 2 ``` Repair: ```polymathplus min: (x - 1)^2 + (y - 1)^2 -1.5 - (x^2 + y^2) > 0 x| 0.5 -2 2 y| 0.5 -2 2 ``` ### 8. Unknown and unrecognized lines Every non-comment, non-blank line outside a table must be one of: - a main statement - an explicit equation - a guess/bounds line - a valid equality constraint - a valid inequality constraint - a table delimiter Invalid standalone expression: ```polymathplus min: (T - 350)^2 + 0.1*W^2 T + W T| 340 300 450 W| 200 0 400 ``` Repair: ```polymathplus min: (T - 350)^2 + 0.1*W^2 T + W - 540 = 0 T| 340 300 450 W| 200 0 400 ``` Invalid unknown variable: ```polymathplus min: (x - 2)^2 + (y - 3)^2 2 - x*t > 0 x| 1 0 10 y| 1 0 10 ``` Repair: ```polymathplus min: (x - 2)^2 + (y - 3)^2 2 - x*y > 0 x| 1 0 10 y| 1 0 10 ``` ## Solver Options Metadata Solver metadata can be added as comment directives: ```polymathplus #@NlpSolver = gr #@Trace = true ``` Common solver names used by solver-side code are: - `gr`: GRG - `al`: Augmented Lagrangian - `ba`: BANLP Current precheck behavior: - These lines are comments/directives for precheck. - NLP precheck does not validate solver option values. - Solver components, not precheck, interpret the metadata. ## Practical Modeling Checklist Before generating or solving an NLP program: - Decide whether the problem is table-free optimization (`min:`) or table-based least squares (`fit:`). - For `fit:`, include exactly one valid data table and keep the dependent variable off the right-hand side. - Write the objective or model expression in valid math syntax. - Add explicit helper equations only when they simplify the model. - Add one guess/bounds line for each decision variable. - Keep every guess inside its bounds. - Convert constraints to `= 0` or `> 0`. - Ensure every variable is defined and used. - Remove duplicate definitions and circular helper equations. ## Examples: Valid Programs ### A. Unconstrained nonlinear optimization ```polymathplus min: (1.5 - x + x*y)^2 + (2.25 - x + x*y^2)^2 + (2.625 - x + x*y^3)^2 x| 1 -4.5 4.5 y| 1 -4.5 4.5 ``` ### B. Constrained nonlinear optimization ```polymathplus min: x1^2 + x2^2 + 2*x3^2 + x4^2 - 5*x1 - 5*x2 - 21*x3 + 7*x4 2*x1^2 + x2^2 + x3^2 + 2*x1 - x2 - x4 - 5 = 0 x1^2 + x2^2 + x3^2 - x1 + x2 - x4 - 8 = 0 x1^2 + 2*x2^2 + x3^2 + 2*x4^2 + x1 + x4 - 10 = 0 x1| 0 -50 50 x2| 1 -50 50 x3| 2 -50 50 x4| -1 -50 50 ``` ### C. Engineering design optimization ```polymathplus pi_val = 4*arctan(1) target_volume = 100 r_min = 0.1 r_max = 5 h_min = 0.1 h_max = 10 min: radius^2 + radius*height pi_val*radius^2*height - target_volume = 0 radius - r_min > 0 r_max - radius > 0 height - h_min > 0 h_max - height > 0 radius| 2 0 30 height| 4 0 30 ``` ### D. Least-squares fit ```polymathplus [ x y 1.309 2.138 1.471 3.421 1.490 3.597 1.565 4.340 1.611 4.882 1.680 5.660 ] fit: y = b1*x^b2 b1| 0.7 0 2 b2| 4.0 0 10 ``` ### E. Constrained least-squares fit ```polymathplus [ x y 0.0 0.91 0.5 1.48 1.0 2.40 1.5 3.73 2.0 5.00 2.5 6.27 3.0 7.60 3.5 8.52 ] fit: y = level/(1 + exp(-rate*(x - center))) level - 0 > 0 rate - 0 > 0 level| 8.0 0 20 rate| 0.8 0 5 center| 1.5 -1 5 ``` ## Verification Notes The rules and examples in this repo-local hardened spec were checked against: - `C:\dev\js\solver_precheck\solver_precheck.js` - NLP valid and invalid cases from `C:\dev\js\solver_precheck\solver_precheckTests.js` The examples were cleaned for documentation use, including simplified names and removal of test-only comments.