FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation Ruoran Xu*
Wending Gao*
arXiv:2607.12982v1 [cs.AI] 14 Jul 2026
Abstract
building a reliable generation framework for analytic geometry poses methodological challenges that existing approaches have not addressed.
Math reasoning has achieved significant progress with the rapid advancement of Multimodal Large Language Models (MLLMs), however analytic geometry remains largely underexplored, primarily due to the scarcity of annotated samples. Existing diagram generation approaches struggle with analytic geometry: template methods cannot handle constraint-driven layouts, and generative models lack the geometric precision to render annotated conic curves correctly. We present FormalAnalyticGeo, a scalable framework for fully automatic generation of multimodal analytic geometry problems. Leveraging the rigor of formal languages, we design the framework around CDL (Condition Description Language), a formal intermediate representation that bridges free-form problem text with precise diagram rendering via a Signed Distance Field (SDF) engine. The framework employs four specialized LLM components in sequence: a Generator that produces diverse analytic geometry problems, a Formalizer that converts each problem into CDL for SDF-based rendering, a Measurer that extracts ground-truth answers through vision-based measurement on the rendered diagrams, and a Quality Verifier that checks outputs at three stages. Structured feedback from the Quality Verifier drives automatic retry, forming a closed loop that eliminates any need for human annotation. Applying FormalAnalyticGeo at scale yields AnalyticGeo7K, a dataset of over 7K verified multimodal problems, each with aligned text, diagram, formal annotation, and ground truth.Experiments show that the generated problems achieve a median ground-truth relative error of 0.70%, with 82.3% of answers falling within 5% of the exact symbolic solution. Our framework and dataset will be publicly released.
1
Qiufeng Wang†
Figure 1: Diagram generation for the same analytic geometry problem. (a) ChatGPT: the circle does not use the focal distance as its diameter, and 𝑃 lies on the circle but not on the hyperbola. (b) Nano Banana: geometrically meaningless output. (c) Gemini 3 Pro: distorted curves and inaccurate point placement. (d) Ours: geometrically exact rendering with known coordinate-to-pixel mapping, enabling direct visual measurement of ground-truth answers.
Introduction
Multimodal Large Language Models (MLLMs) have exhibited impressive performance in mathematical reasoning. However, most existing research on multimodal mathematical reasoning primarily focuses on elementary plane geometry and solid geometry, leaving analytic geometry as a largely underexplored domain, while the capacity to jointly comprehend visual diagrams and complex algebraic structures continues to pose a considerable challenge, it demands an integrated understanding of equations, coordinate systems, geometric figures including conic sections, and the intricate spatial relationships between them. Despite its importance in both education and standardized examinations, the multimodal understanding of analytic geometry by MLLMs remains largely underexplored, in part because existing geometry benchmarks address plane geometry exclusively and the only large-scale conic-section resource (Conic10K [27]) is purely text-based. Automated data generation is therefore essential, yet
We identify three such challenges. (i) Representation gap. Generating multimodal problems requires a formal representation that captures both algebraic relationships and geometric constructions needed to render a diagram. Existing geometry formalisms (InterGPS [17], FormalGeo [35]) target plane geometry and cannot express coordinate systems or conic curves; Conic10K’s [27] Assertional Logic encodes algebraic relations but lacks the construction primitives required for rendering. (ii) Rendering gap. Analytic geometry diagrams involve algebraically defined curves embedded in a coordinate system. Existing tools such as GeoGPT4V [4] are restricted to Euclidean constructions; MAVIS [34] spans analytic geometry but lacks formal text–diagram verification. Traditional plotting libraries require all positions to be pre-computed, offering no mechanism for constraint-driven layout. (iii) Verification
Xi’an Jiaotong-Liverpool University † Corresponding author: [email protected]
* Equal contribution.
1
Xu, Gao, and Wang
gap. Existing generation approaches are single-pass, accepting outputs without cross-stage verification; errors at any stage propagate undetected into the final dataset. We propose FormalAnalyticGeo, a scalable framework that addresses all three challenges through formal language. To close the representation gap, we design CDL (Condition Description Language), a formal intermediate representation that captures both algebraic relations and geometric constructions, enabling automatic consistency checking. To close the rendering gap, we develop an SDF-based rendering engine that compiles CDL programs into differentiable Signed Distance Fields, unifying constraint solving and diagram rendering so that under-determined positions are resolved via gradient descent. To close the verification gap, a Quality Verifier checks each stage’s output at three gate positions and returns structured feedback for automatic retry, forming a closed loop that eliminates any need for human annotation. The framework comprises four stages: a Generator produces diverse problems, a Formalizer translates each into CDL, the SDF engine renders a diagram, and a Measurer extracts ground-truth answers through vision-based measurement on the rendered diagram. Applying FormalAnalyticGeo at scale yields over 7K verified problems, each comprising a natural language question, a standardized diagram, a CDL annotation, and a visually extracted ground-truth answer, with a median relative error of 0.70%. Our main contributions are as follows:
some MLLMs perform better when diagrams are withheld, indicating that models routinely ignore visual content. MATH-Vision [26] extends this to 3,040 competition-level problems across 16 subjects including analytic geometry, with GPT-4V [19] scoring only 23.98%. DynaMath [36] constructs 5,010 variants from 501 seed problems to evaluate VLM robustness under systematic visual perturbations. For plane geometry, GeoQA [6], UniGeo [5], Geometry3K [17], and PGPS9K [32] together supply over 30,000 problems focused on Euclidean constructions (triangles, circles, and quadrilaterals), accompanied by symbolic annotations and program solutions. Analytic geometry remains largely uncovered. GeoEval [31] explicitly includes analytic geometry but contributes fewer than 1% of its corpus.0 Conic10K [27] is the only large-scale conic-section dataset (10,861 problems), with formal AL annotations and multistep reasoning chains, but it is purely text-based: it provides neither rendered diagrams nor a multimodal evaluation protocol. FormalAnalyticGeo directly addresses this gap by providing an annotationfree generation framework that pairs each problem with a standardized, SDF-rendered diagram.
2.2
Automated geometry data generation has taken several forms. AlphaGeometry [25] synthesizes 100 million proof traces by combining a neural language model with a symbolic deduction engine (DDAR), achieving gold-medalist performance on IMO planegeometry problems. R-CoT [14] proposes a two-stage forward-thenreverse pipeline that generates diagram descriptions before deriving problems from them. These approaches are confined to Euclidean proof tasks and produce no multimodal pairs suitable for algebraic or metric reasoning. More recent work targets multimodal geometry data directly. GeoGPT4V [4] uses GPT-4 [19] and GPT-4V [19] with Wolfram Alpha to generate 4.9K plane-geometry problems with diagram images. G-LLaVA [9] converts formal logic representations to Geo170K [9] multimodal pairs, while TrustGeoGen [8] introduces formal-verification guarantees for a Euclidean geometry data engine. NeSyGeo [29] proposes a neuro-symbolic framework that defines an entity-attributerelation DSL and combines symbolic construction with LLM-based question generation to synthesize 100K plane-geometry caption and reasoning samples. AutoGeo [12] and the concurrent SocraticGeo [13] further demonstrate multi-agent pipelines for plane-geometry diagram synthesis. Despite their advances, all of these systems target Euclidean or plane geometry exclusively. Geometry formal languages and formalization methods underpin rendering and reasoning pipelines. Inter-GPS [17] defines 91 geometric predicates for plane-figure logic forms; FormalGeo [35] extends this to 88 predicates and 196 theorems. AutoGPS [22] introduces a Multimodal Problem Formalizer that extracts formal representations from geometry diagrams and text, feeding a Deductive Symbolic Reasoner for interpretable, step-by-step problem solving. Conic10K’s [27] AL formalizes conic-section problems with 90 operators, but AL encodes only algebraic relations and lacks the geometric construction information required to render diagrams (e.g., explicit point positions, intersections, tangent lines). Our CDL
• A closed-loop generation framework: FormalAnalyticGeo decomposes multimodal analytic geometry data generation into specialized stages connected by a formal language, with feedback-driven quality gates eliminating the need for human annotation. • A formal language for analytic geometry: CDL bridges natural language problem descriptions and geometric rendering, enabling automatic syntactic validation and completeness checking. • An SDF-based rendering engine: SDF Engine compiles CDL into differentiable Signed Distance Fields, unifying constraint solving and diagram rendering for exact analytic curves. • A large-scale multimodal dataset: AnalyticGeo7k as a product of the framework, it covers over 7K verified problems with ablation studies validating each component. • Comprehensive Empirical Analysis: We conduct comprehensive experiments on 8 state-of-the-art models and providing actionable insights for advancing multimodal spatial and mathematical reasoning.
2
Related Work
We review related work in three areas: multimodal mathematical reasoning benchmarks, geometry data generation, and multi-agent systems and tool use.
2.1
Geometry Data Generation
Multimodal Math Reasoning Benchmarks
Recent benchmarks have driven rapid progress in multimodal mathematical reasoning. MathVista [16] consolidates 28 existing datasets into a 6,141-problem suite and shows GPT-4V [19] achieves only 49.9% versus 60.3% for humans. MathVerse [33] further reveals that
0 GeoEval contains 28 analytic geometry problems out of 5,050 total.
2
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
extends AL with construction primitives that drive SDF-based rendering. To the best of our knowledge, no prior work has addressed analytic geometry data generation for multimodal benchmarks.
2.3
A key design principle is closed-loop quality control. A dedicated Quality Verifier checks each component’s output at three gate positions using task-specific verification tools. When a check fails, the Quality Verifier returns structured feedback that pinpoints the error and suggests a correction; the upstream component then retries with this feedback as additional context. This feedback-driven retry mechanism is critical, as unverified outputs can actively degrade downstream data quality. Problems that exhaust all retries are discarded, ensuring that only verified data enters the final dataset. All inter-agent communication passes through structured formats (CDL programs, measurement instructions, verification verdicts), and the entire framework runs without human intervention.
LLM Agents and Tool Use
LLM-based agents, characterized by iterative perception, reasoning, and action, have become a dominant paradigm for complex task automation. The ReAct [30] framework structures agent behavior into interleaved reasoning traces and tool-invocation actions, grounding language model outputs in external observations. Multi-agent platforms such as AutoGen [28] and MetaGPT [11] extend this to collaborative pipelines where specialized agents with distinct roles coordinate to solve tasks beyond the capacity of a single model. Tool-augmented reasoning is particularly critical for tasks requiring grounded computation. Toolformer [23] demonstrates that LLMs can autonomously learn to invoke external APIs (calculators, search engines) at appropriate locations. In multi-agent data synthesis, MATRIX [24] and AgenticMath [15] show that specialized generator–verifier pipelines produce higher-quality training data than single-model generation. FormalAnalyticGeo adopts this multi-component paradigm with a domain-specific quality layer. Unlike general-purpose frameworks, our framework embeds a dedicated Quality Verifier equipped with geometry-specific tools including CDL syntax validation, symbolic solvability checking, and cross-component answer verification, applied at three gate positions. This design provides closedloop feedback that drives upstream retries until each generated problem meets measurability and correctness thresholds, yielding annotation-free ground truth for multimodal analytic geometry.
3
3.2
FormalAnalyticGeo
FormalAnalyticGeo is a scalable framework that automatically generates multimodal analytic geometry problems with formally verified text–diagram consistency. Unlike prior data-generation approaches that rely on template-based synthesis or single-model bootstrapping, FormalAnalyticGeo decomposes the task into specialized stages connected by a formal intermediate language and enforced by quality gates with feedback-driven retry. We first give an overview of the framework, then describe Condition Description Language, a formal language that bridges natural language and diagram rendering, and the SDF-based rendering engine. Finally, we detail the LLM components and quality gates that drive the framework end-to-end.
3.1
Condition Description Language
The framework requires a formal intermediate representation that is both human-readable and machine-renderable. Existing formal languages for geometry, such as Assertional Logic [27], were designed for semantic parsing rather than diagram synthesis and lack a direct mapping to visual primitives. We propose CDL (Condition Description Language), a declarative formal language in which every statement maps to either a visual element or a differentiable constraint in the rendering engine. Renderability is the primary design goal: every valid CDL program can be deterministically compiled into an SDF scene. Statement Categories. A CDL program is a sequence of semicolonseparated statements organized into seven categories. Declarations and Equations define geometric objects and their algebraic equations, each creating an SDF primitive with determined parameters. Coordinates fix point positions as non-learnable constants. Derived objects such as Focus, Intersection, and Directrix compute new entities from existing ones via conic-section formulas at parse time. Predicates and Metric constraints assert geometric relationships (e.g., PointOnCurve, IsTangent) and numeric measurements (e.g., Distance, Slope), each mapping to a differentiable loss function for the SDF optimizer (Section 3.3). Inequality constraints restrict parameter ranges for well-posedness. Machine Verifiability. CDL’s formal structure enables two levels of automatic quality control: syntactic validation by the CDL parser, which detects undeclared names and parsing failures with immediate feedback for the Formalizer’s self-correction, and completeness checking by the Quality Verifier, which verifies that all geometric objects in the problem text are encoded in the CDL program (Section 3.4). Scope and Limitations. The current CDL specification covers five primitive types (line, circle, ellipse, parabola, hyperbola), 12 derived-object operators, and metric and predicate constraints sufficient for the five goal types in our dataset. Region-based rendering (e.g., shading the area inside a curve and above a line) is not yet supported, as it requires signed-region SDF composition beyond point-level constraints; we treat this as future work.
Framework Overview
FormalAnalyticGeo is organized as a sequential system in which four specialized LLM components and one deterministic rendering engine collaborate to produce multimodal analytic geometry problems. Each problem comprises four aligned artifacts: a natural language problem text, a formal CDL annotation, a standardized geometric diagram, and a ground-truth answer. The framework proceeds as follows: the Generator produces a problem together with its conic equation, the Formalizer translates the problem into a CDL program (Section 3.2), the SDF engine renders a diagram from the CDL (Section 3.3), and the Measurer extracts the ground-truth answer by measuring the rendered diagram.
3.3
SDF Engine
We now describe the rendering engine that compiles CDL programs into geometric diagrams. Traditional plotting libraries such as Matplotlib and TikZ can render curves at given coordinates but treat 3
Xu, Gao, and Wang
Figure 2: The framework comprises three specialized generative components and one dedicated verification component. Each generative component operates in a task-specific ReAct loop and accepts structured feedback from the Quality Verifier for retry; the Quality Verifier enforces data quality at three gate positions between stages. constraint solving as an external responsibility: when a CDL program specifies that “point 𝑃 lies on ellipse 𝐶 closest to focus 𝐹 ,” the user must resolve 𝑃’s coordinates separately before plotting. We instead adopt Signed Distance Fields (SDFs) as both the geometric representation and the rendering primitive, unifying constraint solving and rendering in a single differentiable framework. Because SDFs are differentiable, under-determined point positions can be resolved automatically via gradient descent over geometric constraints; because rendering reduces to thresholding on a pixel grid, the resulting coordinate-to-pixel mapping is exact – a property the Measurer later exploits for visual ground-truth extraction; and because all geometric elements share the same SDF representation, conic curves, coordinate axes, directrix lines, and asymptotes are rendered through one unified mechanism without element-specific drawing logic. Formally, an SDF is a scalar function 𝐹 : R2 → R that assigns to every point x the signed distance to the nearest boundary of a geometric shape: ( −𝑑 (x, 𝜕Ω) if x ∈ Ω, 𝐹 (x) = (1) 𝑑 (x, 𝜕Ω) if x ∉ Ω,
as PyTorch modules with batch dimensions for GPU-accelerated parallel optimization. Constraints and Optimization. Geometric constraints from the CDL program are compiled into differentiable loss functions over the set of geometric elements 𝐸 = {𝑒 1, 𝑒 2, . . . , 𝑒 𝑁 }. Each constraint 𝑐𝑖 maps a configuration to a non-negative scalar (zero when satisfied), and the optimizer seeks the configuration 𝐸 ∗ that minimizes the total loss: 𝑚 ∑︁ ∑︁ 2 𝑐𝑖 (𝐸) + 𝜆 max 0, 𝜏 − ∥𝑒 𝑗 − 𝑒𝑘 ∥ , (2) 𝐿(𝐸) = 𝑖=1
𝑗 <𝑘
where the second term is a crowd regularization penalty that prevents elements from collapsing into degenerate configurations by penalizing pairs closer than a threshold 𝜏. We optimize 𝐿 with AdamW and cosine-annealing learning rate scheduling over a batch of 𝐵 parallel initializations, selecting the sample with the lowest loss. For fully determined problems where all coordinates are resolved symbolically from the CDL, optimization is skipped entirely. Rendering The boundary of each shape is extracted by sampling the SDF on an 𝑁 ×𝑁 pixel grid and thresholding at the zero-level set. All geometric elements – conic curves, coordinate axes, directrix lines, and asymptotes – are rendered through this unified SDF mechanism, ensuring pixel-level geometric consistency across all element types. The viewport metadata (coordinate bounds, pixel size) is recorded alongside each image as a sidecar file, providing exact coordinate-to-pixel mappings that the Measurer later uses for visual measurement.
where 𝑑 (x, 𝜕Ω) = inf y∈𝜕Ω ∥x − y∥. The zero-level set {x : 𝐹 (x) = 0} recovers the shape boundary exactly. SDF Primitives. We implement SDF primitives for the five geometric element types in analytic geometry: line, circle, ellipse, parabola, and hyperbola. Lines and circles admit standard closedform SDFs. For ellipses and parabolas, we adopt analytical cubic solvers that reduce the closest-point problem to a depressed cubic solvable via Cardano’s formula. For hyperbolas, where no closedform closest-point solution exists, we use the implicit approximation SDFhyp (x) ≈ |𝑓 (x)|/∥∇𝑓 (x)∥, where 𝑓 (x) = 𝑥 2 /𝑎 2 − 𝑦 2 /𝑏 2 − 1 is the implicit equation and ∇𝑓 its gradient; this first-order approximation provides sub-pixel accuracy near the curve and converges to the exact SDF on the zero-level set. All primitives are implemented
3.4
Generator
Given target objects (line, circle, ellipse, hyperbola, or parabola), the Generator produces a natural language problem together with their polynomial equations. It operates in a ReAct loop with four domain-specific tools: a seed retrieval tool that samples real-world raw text from the Conic10K [27] dataset, a property enumeration 4
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
tool that lists the geometric properties derivable from a given equation via SymPy, and two validation tools (rule-based and symbolic) that verify the generated problem’s self-consistency. The Generator supports two generation paths: a forward path in which it freely composes a problem, and a reverse path in which it grounds the problem in symbolically verified properties from the seed library. The reverse path is essential because LLMs often generate problems with incorrect geometric relationships when composing freely; anchoring the generation in SymPy-verified properties significantly reduces such errors. Each problem also carries an explicit information partition: let 𝐼𝑡 denote the conditions stated in the problem text and 𝐼 𝑣 those that must be read from the diagram. The constraint 𝐼 𝑣 ∩ 𝐼𝑡 = ∅ ensures that solving the problem requires both modalities.
3.5
control from a passive filter into an active closed-loop correction process. The three gates are:
• Gate 1 (after problem generation): verifies solvability by attempting a symbolic solution and confirms a finite answer exists. • Gate 2 (after CDL annotation): validates CDL syntax and checks that all geometric objects mentioned in the problem text are encoded in the CDL. • Gate 3 (after visual measurement): checks the answer range for plausibility and cross-validates against a text-only symbolic solution.
Formalizer
Problems that fail all three attempts at any gate are discarded, ensuring that only verified data enters the final dataset.
The Formalizer translates the natural language problem into a CDL program at temperature 0. A key design is grammar prompting: the CDL specification provided to the Formalizer is dynamically tailored to the detected curve type, pruning irrelevant operators (e.g., removing Asymptote for ellipses) and supplying curve-specific few-shot examples. This reduces attention dilution over the full operator set and prevents the Formalizer from hallucinating unsupported constructs. The output CDL is immediately parsed by the CDL parser; any syntactic error triggers an automatic retry with the parser’s error message as feedback, before the result reaches the Quality Verifier.
3.6
4
We apply the framework described in Section 3 to generate the AnalyticGeo7k dataset. This section reports dataset statistics, quality, and diversity.
4.1
Measurer ReAct Loop
Generation Setup
All four components (Generator, Formalizer, Measurer, and Quality Verifier) use Gemini-3.1-Pro-Preview via an OpenAI-compatible API endpoint. The framework runs in streaming mode: each problem is generated, annotated, rendered, measured, and verified endto-end before the next problem begins. Target curve types cycle uniformly among ellipse, hyperbola, parabola, and circle; goal types cycle among chord length, area, distance, angle, and perimeter. The framework produced a total of 7,823 candidate problems. Of these, 780 were discarded because they exhausted all quality-gate retries without passing. This was typically due to persistent CDL annotation errors or rendering failures, leaving a final dataset of 7,043 verified problems. Each problem takes ∼5 minutes to generate on average. As the framework is fully automatic and requires no human annotation, the dataset can be scaled to any target size by running additional generation cycles; the 7,043-problem release reported here represents an initial demonstration of the framework’s capability.
The Measurer extracts ground-truth answers by measuring the rendered diagram. A critical challenge is information leakage: if the Measurer receives both the diagram and the curve equations, the underlying LLM bypasses visual measurement and solves the problem analytically, producing answers that are not true visual ground truth. We address this through physical information isolation by splitting the Measurer into two stages. The Task Extractor reads only the problem text and outputs a structured measurement instruction – specifying what to measure and which entities to locate – that contains no equations or coordinates. The Visual Measurer receives only this instruction and the diagram image; it never sees the problem text or equations. The Visual Measurer operates in a ReAct loop with a suite of computer-vision tools that cover coordinate mapping, distance and angle measurement, curve probing, and intersection detection. Because we rendered the diagram ourselves, the viewport metadata (coordinate bounds, pixel-to-coordinate mapping) is known exactly, eliminating the axis-reading and scale-detection errors common in diagram understanding.
3.7
AnalyticGeo7k
Quality Gates
4.2
Quality Verifier. A dedicated Quality Verifier enforces end-to-end data quality by independently verifying each stage’s output at three gate positions using task-specific tools. On failure, it returns structured feedback that pinpoints the error and suggests a correction; the upstream component retries (up to two additional attempts) with this feedback appended to its context, transforming quality
Dataset Statistics
Table 1 summarizes the dataset composition. The 7,043 problems span four curve types and five goal types. Each curve type contributes 18–32% of the total, ensuring broad coverage across conic sections. Area and chord length are the most frequent goal types, while distance, angle, and perimeter provide complementary geometric reasoning challenges. 5
Xu, Gao, and Wang
Figure 3: Three representative problems generated by FormalAnalyticGeo, with Measurer answers and analytical solutions. Table 1: Curve type × goal type distribution (number of problems).
Table 2: Quality gate pass rates and retry statistics. Gate
Area
Chord
Dist.
Angle
Perim.
Total
Circle Ellipse Hyperbola Parabola
485 558 492 248
537 203 428 307
331 406 219 279
465 221 352 139
436 302 340 295
2,254 1,690 1,831 1,268
Total
1,783
1,475
1,235
1,177
1,373
7,043
4.3
First-Try Pass
Retry Needed
Gate 1 (Problem) Gate 2 (CDL) Gate 3 (Answer)
99.1% 98.2% 95.1%
0.9% 1.8% 4.9%
Formalizer L1 syntax repair
86.6%
13.4%
Ground-Truth Accuracy. To evaluate the accuracy of the Measurer’s visual measurements, we sample 164 problems from the dataset (balanced across curve and goal types) and manually compute their exact symbolic answers. For each sampled problem, we derive the analytical solution using standard analytic geometry techniques and compute the relative error 𝜖 = |𝑎 meas − 𝑎 exact |/|𝑎 exact |. Across the 164 sampled problems, the Measurer achieves a median relative error of 0.70% (mean 2.84%), with 82.3% of answers falling within 5% of the exact solution. Figure 4 shows the accuracy breakdown by curve type and goal type. Most categories ¯ Parabola–area probachieve >95% accuracy (measured as 1 − 𝜖). lems are the hardest category (93.97% accuracy). We attribute this to multi-step visual reasoning: measuring a parabolic segment area requires identifying the tangent line, computing intercepts, and deriving the enclosed area, with each step accumulating measurement error from successive tool calls. This category-specific pattern suggests a fundamental trade-off in visual ground-truth extraction: single-step measurements (distances, angles) are highly
Quality Analysis
We evaluate dataset quality along two dimensions: framework reliability and ground-truth accuracy. Framework Reliability. Table 2 reports pass rates and retry statistics at each quality gate. All three gates achieve ≥99% final pass rate. Gate 1 reaches 99.1% on the first try, indicating that the Generator’s built-in validation tools effectively prevent unsolvable problems from entering the framework. Gate 2 achieves 98.2% firsttry, with the CDL parser’s syntactic auto-repair resolving most issues before the Quality Verifier is invoked; only 1.8% of problems require a Quality Verifier retry. Gate 3 exhibits the highest retry rate (4.9%), reflecting the inherent difficulty of cross-validating visual measurements against symbolic solutions. Problems that exhaust all retries are discarded and replaced. 6
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
accurate, while multi-step derivations amplify per-step errors. Mitigating this accumulation is a direction for future work; potential approaches include intermediate result verification between tool calls and symbolic cross-checking of partial measurements before combining them into a final answer. The 1% evaluation threshold in Table 3 remains reliable under this noise level, as the median GT error (0.70%) is well below the threshold.
33.0% (−52.3 pp) without images. Interestingly, the text-only ranking partially reshuffles: GPT-5.2 overtakes Gemini 3 Flash (42.0% vs. 36.0%), suggesting that some models rely more heavily on visual parsing while others maintain stronger algebraic reasoning in the absence of diagrams.
5.2
Ablation Study
We study four design decisions in FormalAnalyticGeo, each isolating one framework component (Tables 4 and 5). w/o Quality Verifier disables all three quality gates and feedback-driven retry loops, while retaining each component’s internal self-validation tools, so that this variant isolates the contribution of cross-component external verification. w/o Seed Library removes the seed_pool tool from the Generator, eliminating in-context exposure to verified seed problems; because the reverse path accounts for only 3.7% of baseline outputs, the primary effect is the loss of implicit structural priors for forward-path generation. Formalizer Few-shot Gradient re-runs only the Formalizer on 200 existing problems at four fewshot counts (𝑁 ∈ {0, 4, 8, 10}) to measure CDL annotation quality without re-generating problems or diagrams. w/o CV Tools removes all measurement tools from the Visual Measurer, forcing visual parameter estimation from the rendered diagram alone; this variant requires no new data collection since it is evaluated on 200 problems sampled from the 7,043-problem dataset.
¯ zoomed to Figure 4: Per-category ground-truth accuracy (1−𝜖, 85–100%). Parabola–area is the hardest combination (93.97%).
Table 4: Ablation study results (200 problems per variant).
5 Experiment 5.1 Experimental Results
Variant
G3 retry (%)
Within 5% (%)
Mean err. (%)
Full framework
4.9
82.3
2.84
We evaluate eight representative MLLMs on the AnalyticGeo7K benchmark under both image and text-only input modes. Table 3 reports accuracy broken down by five goal types and four curve types. Challenging Nature of Analytic Geometry. The best-performing model, Gemini 3 Flash with image input, achieves an overall accuracy of 77.6%, followed by GPT-5.2 (73.1%) and Claude Opus 4.5 (72.0%). GPT-4o reaches only 23.2%, indicating that analytic geometry problems remain difficult even for frontier MLLMs. Performance drops sharply in text-only mode: the best text-only result (GPT-5.2, 42.0%) trails the best image result by over 35 percentage points, and weaker models such as Mistral Large (18.4%) and GPT-4o (18.8%) fall below 20%. This substantial gap suggests that jointly reasoning about coordinate systems, algebraic curves, and geometric relationships poses a significant challenge to current models. Moreover, no single model dominates all fine-grained categories: Claude Opus 4.5 leads on Area (79.4%) and Angle (88.0%) but ranks only third on Chord, while GPT-5.2 leads on Distance (81.3%) but falls behind on Area (68.0%), indicating complementary strengths across goal types and curve families. Impact of Visual Input. Image-input accuracy substantially exceeds text-only performance for all models, confirming that diagrams provide informative visual cues for analytic geometry reasoning. Gemini 3 Flash exhibits the largest gap (77.6% → 36.0%, −41.6 pp), while GPT-5.2 shows a smaller but still significant drop (73.1% → 42.0%, −31.1 pp). The gap is especially pronounced on specific curve types: Gemini’s Circle accuracy drops from 85.3% to
w/o Quality Verifier w/o Seed Library w/o CV Tools
— 26.5 —
45.5 72.9 49.0
35.7 9.92 40.5
7
Table 5: Formalizer few-shot gradient (200 problems, balanced curve types). Few-shot 𝑁
L1 first-try (%)
Avg. attempts
0 (zero-shot) 4 8 10 (baseline)
60.0 62.0 76.0 84.0
1.58 1.48 1.34 1.18
Removing all Quality Verifier gates causes a dramatic accuracy drop: within-5% accuracy falls from 82.3% to 45.5% and mean relative error rises from 2.84% to 35.7%. CDL completeness remains 100% under human review, indicating the degradation stems not from missing problem structure but from compounded visual measurement errors in the Visual Measurer that the gate’s solve_text_only verification would have caught and triggered retries for. This confirms that cross-component external verification provides a substantial quality lift over each component’s selfvalidation alone. Removing seed library access from the Generator increases the Gate 3 retry rate from 4.9% to 26.5%, reflecting that forward-path
Xu, Gao, and Wang
Table 3: Model performance on AnalyticGeo7K benchmark (%). Accuracy = answer within 1% relative error of ground truth. The best and second best results per section are highlighted.
Goal Type Model
Overall
Area
Chord
Dist.
Angle
Perim.
Circle
Ellipse
Hyper.
Parab.
Image Input GPT-4o [20] Claude Sonnet 4 [2] Qwen-VL-Max [3] Claude Opus 4.5 [1] GPT-5.2 [21] Gemini 3 Flash [10]
23.2 49.4 69.0 72.0 73.1 77.6
23.8 59.5 69.6 79.4 68.0 74.3
14.3 42.9 53.9 60.9 64.1 71.0
24.1 41.4 70.3 68.5 81.3 78.7
37.0 59.3 79.9 88.0 79.8 85.3
19.4 41.9 74.9 70.0 76.4 78.1
24.5 60.4 66.5 79.0 72.0 85.3
20.5 59.0 80.2 82.3 76.0 76.2
23.3 34.9 65.4 61.0 73.4 71.4
24.1 37.9 71.9 62.9 70.5 68.3
Text Only Mistral Large [18] GPT-4o [20] Claude Sonnet 4 [2] DeepSeek-V3.1 [7] Qwen-VL-Max [3] Gemini 3 Flash [10] Claude Opus 4.5 [1] GPT-5.2 [21]
18.4 18.8 25.0 30.9 35.0 36.0 38.0 42.0
26.1 26.7 32.5 33.9 31.0 43.7 46.0 44.6
12.2 12.5 12.1 14.2 14.0 19.4 18.0 20.0
16.3 16.7 17.3 29.6 38.2 24.0 29.9 35.8
12.5 6.2 39.2 54.2 64.7 41.4 57.9 62.8
24.2 30.8 24.4 32.5 35.1 50.9 42.5 50.7
18.6 19.0 28.3 30.9 32.7 33.0 38.7 40.4
24.5 25.0 39.0 43.6 46.8 49.1 58.1 57.0
11.5 11.8 17.5 23.8 28.2 41.2 32.0 39.3
19.6 20.0 14.1 26.2 34.6 15.9 24.4 29.0
problems are geometrically less well-formed without in-context structural priors from verified examples. Within-5% accuracy drops 9.4 percentage points to 72.9% and mean error rises to 9.92%, despite Gate 1 and Gate 2 pass rates remaining unaffected, confirming that the seed library’s contribution lies not in enabling generation but in improving the geometric coherence of generated problems. Without CV tools, the Visual Measurer is forced to visually estimate geometric parameters and apply analytical formulas, compounding parameter-reading errors into the final answer: a small misread of an ellipse’s semi-axis 𝑎, for example, propagates through the chord-length formula to yield errors of 30–80%. Within-5% accuracy drops to 49.0% and mean relative error rises to 40.5%, a 33.3 percentage point decline that directly quantifies the contribution of structured pixel-level measurement to GT extraction precision. Table 5 shows a monotone positive trend: L1 first-try pass rate rises from 60.0% to 84.0% as 𝑁 increases from 0 to 10, and average attempts decrease from 1.58 to 1.18. The largest single gain (+14 pp) occurs between 𝑁 = 4 and 𝑁 = 8, where most curve types first receive at least three curve-specific examples; below this threshold, certain types have only one example, insufficient for the Formalizer to infer CDL’s predicate names and argument ordering.
6
Curve Type
7K verified problems with a median ground-truth error of 0.70%. Ablation experiments confirm that each component contributes measurably: removing the Quality Verifier drops within-5% accuracy from 82.3% to 45.5%, and disabling CV tools raises mean error from 2.84% to 40.5%. The CDL specification and SDF engine are designed to be extensible; broader analytic geometry categories such as locus problems and parametric equations can be incorporated by adding corresponding primitives without modifying the core framework.
References [1] Anthropic. 2025. Introducing Claude Opus 4.5. https://www.anthropic.com/ news/claude-opus-4-5. Blog post. [2] Anthropic. 2025. System Card: Claude Opus 4 & Claude Sonnet 4. https://wwwcdn.anthropic.com/6be99a52cb68eb70eb9572b4cafad13df32ed995.pdf. System card. [3] Shuai Bai, Keqin Chen, Xuejing Liu, Jialin Wang, Wenbin Ge, Sibo Song, Kai Dang, Peng Wang, Shijie Wang, Jun Tang, Humen Zhong, Yuanzhi Zhu, Mingkun Yang, Zhaohai Li, Jianqiang Wan, Pengfei Wang, Wei Ding, Zheren Fu, Yiheng Xu, Jiabo Ye, Xi Zhang, Tianbao Xie, Zesen Cheng, Hang Zhang, Zhibo Yang, Haiyang Xu, and Junyang Lin. 2025. Qwen2.5-VL Technical Report. arXiv:2502.13923 [cs.CV] https://arxiv.org/abs/2502.13923 [4] Shihao Cai, Keqin Bao, Hangyu Guo, Jizhi Zhang, Jun Song, and Bo Zheng. 2024. GeoGPT4V: Towards Geometric Multi-modal Large Language Models with Geometric Image Generation. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, Yaser Al-Onaizan, Mohit Bansal, and Yun-Nung Chen (Eds.). Association for Computational Linguistics, Miami, Florida, USA, 750–766. doi:10.18653/v1/2024.emnlp-main.44 [5] Jiaqi Chen, Tong Li, Jinghui Qin, Pan Lu, Liang Lin, Chongyu Chen, and Xiaodan Liang. 2022. UniGeo: Unifying Geometry Logical Reasoning via Reformulating Mathematical Expression. arXiv:2212.02746 [cs.AI] https://arxiv.org/abs/2212. 02746 [6] Jiaqi Chen, Jianheng Tang, Jinghui Qin, Xiaodan Liang, Lingbo Liu, Eric Xing, and Liang Lin. 2021. GeoQA: A Geometric Question Answering Benchmark Towards Multimodal Numerical Reasoning. In Findings of the Association for Computational Linguistics: ACL-IJCNLP 2021, Chengqing Zong, Fei Xia, Wenjie
Conclusion
We presented FormalAnalyticGeo, a scalable framework that generates multimodal analytic geometry problems without human annotation. By unifying CDL as a formal intermediate representation, SDF-based rendering for geometrically exact diagrams, and a four-component generation loop supervised by a Quality Verifier with feedback-driven retries, the framework produces over 8
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
Li, and Roberto Navigli (Eds.). Association for Computational Linguistics, Online, 513–523. doi:10.18653/v1/2021.findings-acl.46 [7] DeepSeek-AI. 2025. DeepSeek-V3 Technical Report. arXiv:2412.19437 [cs.CL] https://arxiv.org/abs/2412.19437 [8] Daocheng Fu, Jianlong Chen, Renqiu Xia, Zijun Chen, Qi Liu, Yuan Feng, Hongbin Zhou, Renrui Zhang, Shiyang Feng, Peng Gao, Hongyuan Zha, Junchi Yan, Botian Shi, Yu Qiao, and Bo Zhang. 2026. TrustGeoGen: Formal-Verified Data Engine for Trustworthy Multi-modal Geometric Problem Solving. arXiv:2504.15780 [cs.AI] https://arxiv.org/abs/2504.15780 [9] Jiahui Gao, Renjie Pi, Jipeng Zhang, Jiacheng Ye, Wanjun Zhong, Yufei Wang, Lanqing HONG, Jianhua Han, Hang Xu, Zhenguo Li, and Lingpeng Kong. 2025. G-LLaVA: Solving Geometric Problem with Multi-Modal Large Language Model. In The Thirteenth International Conference on Learning Representations. https: //openreview.net/forum?id=px1674Wp3C [10] Google DeepMind. 2025. Gemini 3 Flash. https://deepmind.google/models/ gemini/flash/. Model card available at https://deepmind.google/models/modelcards/gemini-3-flash/. [11] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. 2024. MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. In The Twelfth International Conference on Learning Representations. https: //openreview.net/forum?id=VtmBAGCN7o [12] Zihan Huang, Tao Wu, Wang Lin, Shengyu Zhang, Jingyuan Chen, and Fei Wu. 2025. AutoGeo: Automating Geometric Image Dataset Creation for Enhanced Geometry Understanding. IEEE Transactions on Multimedia 27 (2025), 3105–3116. doi:10.1109/TMM.2025.3557720 [13] Zhengbo Jiao, Shaobo Wang, Zifan Zhang, Wei Wang, Bing Zhao, Hu Wei, and Linfeng Zhang. 2026. Socratic-Geo: Synthetic Data Generation and Geometric Reasoning via Multi-Agent Interaction. arXiv:2602.03414 [cs.CV] https://arxiv. org/abs/2602.03414 [14] Deng Linger, Linghao Zhu, Yuliang Liu, Yu Wang, Qunyi Xie, Jingjing Wu, Gang Zhang, Yingying Zhu, and Xiang Bai. 2025. Theorem-Validated Reverse Chain-of-Thought Problem Generation for Geometric Reasoning. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, Christos Christodoulopoulos, Tanmoy Chakraborty, Carolyn Rose, and Violet Peng (Eds.). Association for Computational Linguistics, Suzhou, China, 718–735. doi:10.18653/v1/2025.emnlp-main.38 [15] Xianyang Liu, Yilin Liu, Shuai Wang, Hao Cheng, Andrew Estornell, Yuzhi Zhao, Jun Shu, and Jiaheng Wei. 2026. AgenticMath: Enhancing LLM Reasoning via Agentic-based Math Data Generation. arXiv:2510.19361 [cs.CL] https://arxiv. org/abs/2510.19361 [16] Pan Lu, Hritik Bansal, Tony Xia, Jiacheng Liu, Chunyuan Li, Hannaneh Hajishirzi, Hao Cheng, Kai-Wei Chang, Michel Galley, and Jianfeng Gao. 2024. MathVista: Evaluating Mathematical Reasoning of Foundation Models in Visual Contexts. In International Conference on Learning Representations (ICLR). [17] Pan Lu, Ran Gong, Shibiao Jiang, Liang Qiu, Siyuan Huang, Xiaodan Liang, and Song-Chun Zhu. 2021. Inter-GPS: Interpretable Geometry Problem Solving with Formal Language and Symbolic Reasoning. In The Joint Conference of the 59th Annual Meeting of the Association for Computational Linguistics and the 11th International Joint Conference on Natural Language Processing (ACL-IJCNLP 2021). [18] Mistral AI. 2024. Mistral Large. https://mistral.ai/news/mistral-large Blog post. [19] OpenAI. 2024. GPT-4 Technical Report. arXiv:2303.08774 [cs.CL] https://arxiv. org/abs/2303.08774 [20] OpenAI. 2024. GPT-4o System Card. arXiv:2410.21276 [cs.CL] https://arxiv.org/ abs/2410.21276 [21] OpenAI. 2025. Introducing GPT-5.2. https://openai.com/index/introducing-gpt5-2/. Blog post. System card available at https://cdn.openai.com/pdf/3a4153c8c748-4b71-8e31-aecbde944f8d/oai_5_2_system-card.pdf. [22] Bowen Ping, Minnan Luo, Zhuohang Dang, Chenxi Wang, and Chengyou Jia. 2026. AutoGPS: Automated Geometry Problem Solving via Multimodal Formalization and Deductive Reasoning. In The Fourteenth International Conference on Learning Representations. https://openreview.net/forum?id=PVtZnUh04m [23] Timo Schick, Jane Dwivedi-Yu, Roberto Dessi, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language Models Can Teach Themselves to Use Tools. In Thirtyseventh Conference on Neural Information Processing Systems. https://openreview. net/forum?id=Yacmpz84TH [24] Shuo Tang, Xianghe Pang, Zexi Liu, Bohan Tang, Rui Ye, Tian Jin, Xiaowen Dong, Yanfeng Wang, and Siheng Chen. 2025. Synthesizing Post-Training Data for LLMs through Multi-Agent Simulation. In Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), Wanxiang Che, Joyce Nabende, Ekaterina Shutova, and Mohammad Taher Pilehvar (Eds.). Association for Computational Linguistics, Vienna, Austria, 23306–23335. doi:10. 18653/v1/2025.acl-long.1136 [25] Trieu Trinh, Yuhuai Wu, Quoc Le, He He, and Thang Luong. 2024. Solving Olympiad Geometry without Human Demonstrations. Nature (2024). doi:10.
1038/s41586-023-06747-5 [26] Ke Wang, Junting Pan, Weikang Shi, Zimu Lu, Houxing Ren, Aojun Zhou, Mingjie Zhan, and Hongsheng Li. 2024. Measuring Multimodal Mathematical Reasoning with MATH-Vision Dataset. In The Thirty-eight Conference on Neural Information Processing Systems Datasets and Benchmarks Track. https://openreview.net/ forum?id=QWTCcxMpPA [27] Haoyi Wu, Wenyang Hui, Yezeng Chen, Weiqi Wu, Kewei Tu, and Yi Zhou. 2023. Conic10K: A Challenging Math Problem Understanding and Reasoning Dataset. In Findings of the Association for Computational Linguistics: EMNLP 2023, Houda Bouamor, Juan Pino, and Kalika Bali (Eds.). Association for Computational Linguistics, Singapore, 6444–6458. doi:10.18653/v1/2023.findings-emnlp.427 [28] Qingyun Wu, Gagan Bansal, Jieyu Zhang, Yiran Wu, Beibin Li, Erkang Zhu, Li Jiang, Xiaoyun Zhang, Shaokun Zhang, Jiale Liu, Ahmed Hassan Awadallah, Ryen W White, Doug Burger, and Chi Wang. 2024. AutoGen: Enabling NextGen LLM Applications via Multi-Agent Conversations. In First Conference on Language Modeling. https://openreview.net/forum?id=BAakY1hNKS [29] Weiming Wu, Jin Ye, Zi kang Wang, Zhi Zhou, Yu-Feng Li, and Lan-Zhe Guo. 2025. NeSyGeo: A Neuro-Symbolic Framework for Multimodal Geometric Reasoning Data Generation. arXiv:2505.17121 [cs.CL] https://arxiv.org/abs/2505.17121 [30] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. ReAct: Synergizing Reasoning and Acting in Language Models. In International Conference on Learning Representations (ICLR). [31] Jiaxin Zhang, Zhong-Zhi Li, Ming-Liang Zhang, Fei Yin, Cheng-Lin Liu, and Yashar Moshfeghi. 2024. GeoEval: Benchmark for Evaluating LLMs and MultiModal Models on Geometry Problem-Solving. In Findings of the Association for Computational Linguistics: ACL 2024, Lun-Wei Ku, Andre Martins, and Vivek Srikumar (Eds.). Association for Computational Linguistics, Bangkok, Thailand, 1258–1276. doi:10.18653/v1/2024.findings-acl.73 [32] Ming-Liang Zhang, Fei Yin, and Cheng-Lin Liu. 2023. A Multi-Modal Neural Geometric Solver with Textual Clauses Parsed from Diagram. In IJCAI. [33] Renrui Zhang, Dongzhi Jiang, Yichi Zhang, Haokun Lin, Ziyu Guo, Pengshuo Qiu, Aojun Zhou, Pan Lu, Kai-Wei Chang, Peng Gao, et al. 2024. MathVerse: Does Your Multi-modal LLM Truly See the Diagrams in Visual Math Problems? arXiv preprint arXiv:2403.14624 (2024). [34] Renrui Zhang, Xinyu Wei, Dongzhi Jiang, Yichi Zhang, Ziyu Guo, Chengzhuo Tong, Jiaming Liu, Aojun Zhou, Bin Wei, Shanghang Zhang, Peng Gao, and Hongsheng Li. 2024. MAVIS: Mathematical Visual Instruction Tuning. arXiv:2407.08739 [cs.CV] https://arxiv.org/abs/2407.08739 [35] Xiaokai Zhang, Na Zhu, Yiming He, Jia Zou, Qike Huang, Xiaoxiao Jin, Yanjun Guo, Chenyang Mao, Yang Li, Zhe Zhu, Dengfeng Yue, Fangzhen Zhu, Yifan Wang, Yiwen Huang, Runan Wang, Cheng Qin, Zhenbing Zeng, Shaorong Xie, Xiangfeng Luo, and Tuo Leng. 2024. FormalGeo: An Extensible Formalized Framework for Olympiad Geometric Problem Solving. arXiv:2310.18021 [cs.AI] https://arxiv.org/abs/2310.18021 [36] Chengke Zou, Xingang Guo, Rui Yang, Junyu Zhang, Bin Hu, and Huan Zhang. 2024. DynaMath: A Dynamic Visual Benchmark for Evaluating Mathematical Reasoning Robustness of Vision Language Models.
9
Xu, Gao, and Wang
This appendix provides the complete operator catalog of the Condition Description Language (CDL) introduced in Section 3.2. A CDL program is a sequence of semicolon-separated statements that collectively specify an analytic-geometry diagram suitable for rendering.
CDL distinguishes three tangent-related operators. TangentOnPoint(P, G) computes the tangent line to curve 𝐺 at a point 𝑃 that already lies on 𝐺, via implicit differentiation of the curve equation. TangentOfPoint(P, G) finds tangent lines from an external point 𝑃 to 𝐺 using discriminant analysis and may yield multiple solutions. TangentPoint(l, G) returns the contact point(s) where a known tangent line 𝑙 touches 𝐺.
Declarations and Equations. Every geometric object must be declared with a name and a type before use. Supported types include Point, Origin (fixed at the coordinate origin (0, 0)), Line, Circle, Ellipse, Hyperbola, Parabola, and Number (an algebraic parameter). An Equation statement binds an algebraic equation to a declared curve or line; the parser classifies the equation by discriminant analysis of the general quadratic form 𝐴𝑥 2 + 𝐵𝑥𝑦 + 𝐶𝑦 2 + 𝐷𝑥 + 𝐸𝑦 + 𝐹 = 0 and extracts the curve parameters automatically. A Coordinate statement fixes a point at a specified position. Table 6 lists all 35 operators, organized into three categories: derived-object operators, predicates, and metric constraints.
Predicates. Each predicate asserts a geometric relationship and compiles to a differentiable SDF constraint whose satisfaction corresponds to a zero loss value. For instance, PointOnCurve(P, G) penalizes the signed distance from 𝑃 to 𝐺, while IsTangent(l, G) enforces that the discriminant of the line–curve intersection system vanishes. IsInTangent and IsOutTangent constrain the distance between two circle centers to equal |𝑟 1 − 𝑟 2 | or 𝑟 1 + 𝑟 2 , respectively. Predicates carry no explicit numeric target; they are satisfied when the constraint residual reaches zero.
A
CDL Specification
Metric Constraints. A metric constraint binds a geometric measurement to a target value, creating a loss term |𝑓measured − 𝑓target |. The measurement function is evaluated from the current configuration: Distance computes Euclidean distance, Area uses the crossproduct formula, and AngleOf applies the law of cosines. Algebraic parameters declared as Number may appear as targets, enabling parametric constraints such as Length(SemiMajorAxis(G)) = a.
Table 6: Complete CDL operator catalog: 12 derived-object operators, 8 predicates, and 15 metric constraints. Derived-Object Operators — compute new entities from existing ones Focus(curve, [dir]) → Point Vertex(curve, [dir]) → Point Center(curve) → Point Directrix(curve, [dir]) → Line Asymptote(hyp.) → Lines MidPoint(pt, pt) → Point Intersection(obj, obj) → Points TangentOnPoint(pt, crv) → Line TangentOfPoint(pt, crv) → Lines TangentPoint(ln, crv) → Point Projection(pt, axis/ln) → Point FootPoint(pt, ln) → Point
Inequality Constraints and Auxiliary Wrappers. Inequality constraints (e.g., a > 0; a > b) restrict the admissible ranges of algebraic parameters. CDL also provides auxiliary wrappers for composing references inside other operators:
Predicates — assert geometric relationships (SDF constraint) PointOnCurve(P, G): 𝑃 on 𝐺 IsPerpendicular(l1, l2): 𝑙 1 ⊥ 𝑙 2 IsParallel(l1, l2): 𝑙 1 ∥ 𝑙 2 IsTangent(l, G): 𝑙 tangent to 𝐺 IsChordOf(l, G): chord of 𝐺 IsDiameter(seg, C): diameter of 𝐶 IsInTangent(C1, C2): int. tangent IsOutTangent(C1, C2): ext. tangent
• LineSegmentOf(A, B) — line segment through 𝐴 and 𝐵. • OverlappingLine(. . . ) — the full line through two points. • RightPart(G), LeftPart(G) — individual branches of a hyperbola. • TriangleOf(A, B, C), VectorOf(A, B) — point-tuple wrappers for area/perimeter and dot-product metrics.
Metric Constraints — numeric measurements; illustrative examples Distance(P, F1) = 2 Slope(l) = 3 Eccentricity(G) = 1/2 FocalLength(G) = 6 HalfFocalLength(G) = 3 Inclination(l) = pi/4 Length(SemiMajorAxis(G)) = 3 Area(TriangleOf(A,O,B)) = 4 Perimeter(TriangleOf(A,B,C)) = 12 Abs(LineSegmentOf(A,B)) = 5 AngleOf(P, F1, F2) = 90 XCoordinate(P) = 3 YCoordinate(P) = -1 Quadrant(P) = 1 DotProduct(VectorOf(A,B), VectorOf(C,D)) = 0
Worked Example. The following CDL program encodes the prob2
𝑦2
lem: “From the left focus 𝐹 1 of the hyperbola 𝑥16 − 25 = 1, draw a line tangent to the circle 𝑥 2 + 𝑦 2 = 16, touching it at point 𝑇 . Extend 𝐹 1𝑇 to meet the right branch at 𝑃, and let 𝑀 be the midpoint of 𝐹 1 𝑃.” G: Hyperbola; H: Circle; F1: Point; Z: Line T: Point; P: Point; M: Point; O: Origin Equation(G) = x^2/16 - y^2/25 = 1 Equation(H) = x^2 + y^2 = 16 Focus(G, left) = F1 TangentOfPoint(F1, H) = Z TangentPoint(Z, H) = T Intersection(OverlappingLine(LineSegmentOf(F1, T)), RightPart(G)) = P MidPoint(LineSegmentOf(F1, P)) = M
Derived Objects. Derived-object operators compute new geometric entities from existing ones. Operators that produce points (e.g., Focus, MidPoint) evaluate symbolically at parse time from the parent curve’s parameters. Intersection is resolved analytically by substitution into the curve equation and may return multiple points via set-assignment syntax: {A, B} = Intersection(l, G) Focus, Vertex, and Directrix accept an optional direction parameter drawn from {left, right, upper, lower}. It may be omitted when the curve admits a unique instance, e.g., the single focus of a parabola. In Table 6, square brackets denote optional arguments. Note that Projection maps a point onto a coordinate axis (or an axis-aligned line), whereas FootPoint computes the perpendicular foot from a point onto an arbitrary line.
This nine-statement program declares four points, one line, and two curves. It derives the left focus symbolically, computes the tangent line via discriminant analysis, intersects the extended ray with the right branch of the hyperbola, and determines the midpoint 𝑀. The CDL parser compiles these statements into constraint tuples that are consumed by the SDF-based rendering engine. 10
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
B
B.3
Signed Distance Field Formulation and Constraint Details
In this appendix, we provide a comprehensive mathematical formulation of the Signed Distance Field (SDF) representation, the differentiable loss functions for geometric constraints, the optimization procedure, and the boundary extraction method used in our diagram synthesis engine. This material supplements the description in Section 3.3 of the main paper.
B.1
In analytic geometry, most geometric quantities are determined analytically from the curve equation: foci, vertices, asymptotes, directrices, and intersection points are all computed symbolically by the CDL parser. Consequently, the majority of diagrams require no gradient-based optimisation—the SDF objects are constructed with fixed parameters and rendered directly. Optimisation is invoked only when the diagram contains free points whose positions are constrained but not uniquely determined by the equations (e.g., a point on a curve satisfying an additional distance constraint). In such cases, the synthesis process minimises:
SDF Definition and Basic Representations
A Signed Distance Field (SDF) is a scalar field that assigns to every point x ∈ R2 the signed distance to the closest point on the boundary of a geometric shape. Formally, for a shape Ω ⊂ R2 with boundary 𝜕Ω, the SDF 𝐹 (x) is defined as: min ∥x − y∥, y∈𝜕Ω 𝐹 (x) = − min ∥x − y∥, y∈𝜕Ω
𝐿total (E) = 𝐿constraints (E) + 𝜆𝐿crowd (E), where 𝐿constraints sums the individual constraint losses from Table 8 and 𝜆 = 0.1 balances the crowd regularisation. The optimisation uses AdamW with cosine annealing. Key hyperparameters are listed in Table 9. The optimisation is terminated early if the loss falls below the convergence threshold, indicating that all constraints are satisfied within tolerance.
if x is outside Ω, if x is inside Ω,
where the sign convention follows the common “outside positive, inside negative” rule. Equivalently, the unsigned distance is given by:
B.4
𝑑 (x, 𝜕Ω) = inf ∥x − y∥, y∈𝜕Ω
Boundary Extraction and Visualization
The final diagram is produced by sampling all SDF fields on a regular grid (typically 512 × 512 pixels) and applying a visibility threshold 𝜏vis . A pixel at position x is drawn as part of curve 𝐺𝑖 if |𝐹𝑖 (x)| ≤ 𝜏vis , where 𝜏vis = 1.5 Δ and Δ is the pixel size in data coordinates. Each curve is assigned a distinct colour via HSV saturation; coordinate axes are rendered in black. Point labels (e.g., 𝐹 1 , 𝐴) and axis labels (𝑥, 𝑦, 𝑂) are overlaid via matplotlib text. This threshold-based rendering produces clean, anti-aliased curves at any resolution without explicit curve tracing. We conclude this appendix with a step-by-step example that illustrates the rendering pipeline from a CDL program to the final synthesised diagram. Consider the following analytic-geometry problem:
and the sign is determined by a point-in-polygon test for polygons or by the side of the curve for lines and circles. In our framework, each geometric element is represented by its own SDF, which depends on a small set of continuous parameters. Table 7 lists the SDF expressions for all primitives used in our rendering engine, covering both basic elements and analytic-geometry curves. The basic primitives (point, line, segment, circle) admit closedform SDF expressions. For ellipses and parabolas, we adopt the analytical method of Quílez: the closest-point problem reduces to a depressed cubic, solved via Cardano’s formula when the discriminant 𝑑 ≥ 0 or a trigonometric substitution when 𝑑 < 0. For hyperbolas, an exact SDF would require solving a quartic; we instead use the implicit approximation |𝑓 |/∥∇𝑓 ∥, which is accurate near the curve boundary where rendering occurs. All expressions are continuous and differentiable almost everywhere, making them suitable for gradient-based optimization and threshold-based rendering.
B.2
Optimization Algorithm and Hyperparameters
2
“The ellipse 𝑥4 +𝑦 2 = 1 has foci 𝐹 1 (left) and 𝐹 2 (right). A line 𝑙 through 𝐹 1 with slope 1 intersects the ellipse at points 𝐴 and 𝐵. Find the perimeter of △𝐴𝐵𝐹 2 .” Step 1: CDL formalization. The Formalizer converts the problem text into CDL: G: Ellipse; l: Line; F1: Point; F2: Point A: Point; B: Point; O: Origin Equation(G) = x^2/4 + y^2 = 1 Focus(G, left) = F1; Focus(G, right) = F2 PointOnCurve(F1, l); Slope(l) = 1 {A, B} = Intersection(l, G)
Geometric Constraint Loss Functions
Geometric relationships between elements are encoded as differentiable loss functions that become zero when the constraint is satisfied. Table 8 summarises the key constraints. Each loss is nonnegative and smooth. The point-on-curve constraint directly uses the SDF value: for a point 𝑃 that should lie on curve 𝐺, the loss is 𝐹𝐺 (𝑃), which reaches zero exactly on the curve boundary. The tangency constraint substitutes the line equation into the curve equation and penalises the absolute value of the discriminant; when the discriminant vanishes, the line is tangent. The crowd penalty prevents distinct points from collapsing to the same location during optimisation; it is vectorised for efficient GPU computation.
Step 2: Parsing. The CDL parser classifies√the equation as an ellipse with 𝑎 = 2, 𝑏 = 1, extracts the foci at (± 3, 0), computes the line equation from the slope and focus, and solves the line–ellipse intersection analytically. All geometric quantities are determined from the equation parameters; no optimisation is needed. Step 3: SDF construction. The SDF mapper creates SDF objects for the ellipse (Quilez cubic solver), the line (signed perpendicular 11
Xu, Gao, and Wang
Table 7: SDF expressions for all geometric primitives in our rendering engine. Primitive
SDF 𝐹 (𝑥, 𝑦)
Method
Basic Primitives Point p = (𝑝𝑥 , 𝑝 𝑦 )
√︁
Exact
(𝑥 − 𝑝𝑥 ) 2 + (𝑦 − 𝑝 𝑦 ) 2 |(𝑦 − 𝑎 𝑦 )(𝑏𝑥 − 𝑎𝑥 ) − (𝑥 − 𝑎𝑥 )(𝑏 𝑦 − 𝑎 𝑦 )| ∥b − a∥ · (b−a) ∥x − a − clamp(𝑡, 0, 1)(b − a)∥, 𝑡 = (x−a) ∥b−a∥ 2 ∥x − c∥ − 𝑟
Line through a, b Segment ab Circle (c, 𝑟 )
Exact Exact Exact
Analytic Geometry Curves 2
𝑦2
Ellipse 𝑥𝑎2 + 𝑏 2 = 1 Parabola 𝑦 2 = 4𝑝𝑥 2
𝑦2
Hyperbola 𝑥𝑎2 − 𝑏 2 = 1
Closest-point via cubic equation (Cardano / trigonometric branch) Closest-point via cubic equation; four directions (up/down/left/right) |𝑓 (x)| 2 𝑦2 2𝑦 , 𝑓 = 𝑥𝑎2 − 𝑏 2 − 1, ∇𝑓 = ( 𝑎2𝑥2 , − 𝑏 2 ) ∥∇𝑓 (x)∥
Table 8: Differentiable loss functions for geometric constraints used in analytic-geometry rendering. Constraint
Loss Function
Equality 𝐴 = 𝐵 Inequality 𝐴 ≤ 𝐵 Point on curve 𝑃 ∈ 𝐺 Slope of line 𝑙 equals 𝑚 Perpendicularity 𝑙 1 ⊥ 𝑙 2
|𝐴 − 𝐵| max(𝐴 − 𝐵, 0) 𝐹𝐺 (𝑃) |slope(𝑙) − 𝑚| |v1 · v2 | ! ® · 𝐵𝐶 ® 𝐵𝐴 arccos ® ∥ 𝐵𝐶 ® ∥ ∥ 𝐵𝐴∥ 1 |(B − A) × (C − A)| 2 √︁ (𝑝𝑥 − 𝑞𝑥 ) 2 + (𝑝 𝑦 − 𝑞 𝑦 ) 2 Discriminant of 𝑙 ∩ 𝐺 = 0 ∑︁ 2 max 0, 𝜏 − ∥x𝑖 − x 𝑗 ∥
Angle ∠𝐴𝐵𝐶 Area of △𝐴𝐵𝐶 Distance ∥𝑃𝑄 ∥ Tangency (line 𝑙 tangent to 𝐺) Crowd penalty
Table 9: Optimisation hyperparameters.
Value
Optimiser Maximum iterations Initial learning rate Final learning rate Learning rate schedule Convergence threshold (loss) Crowd penalty threshold 𝜏 Batch size
AdamW 10 000 0.1 1 × 10−6 Cosine annealing 0.1 0.2 (relative to diagram scale) variable (up to 2048)
Approx.
𝐹 1 , the intersection points 𝐴 and 𝐵, and the foci, with a coordinate system.
𝑖< 𝑗
Parameter
Exact Exact
distance), and the coordinate axes. Each object defines a scalar field 𝐹𝑖 (x) over R2 . Step 4: Rendering. The renderer samples all SDF fields on a 512 × 512 grid and applies the threshold |𝐹𝑖 (x)| ≤ 1.5 · Δ, where Δ is the pixel size. Pixels passing the threshold are coloured by curve identity. Point labels and axis annotations are overlaid via matplotlib. The resulting diagram shows the ellipse, the line through 12
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
C
Prompt Design
- "A line intersects the circle. Find chord length." -- TOO VAGUE - "Find the area of triangle ABC." -- undefined, where are A, B, C? - "Based on the measurements in the diagram..." -- no measurements
This appendix presents the complete system prompts for each framework component. All components operate in ReAct loops with function-calling; the prompts below govern the system message that precedes each loop.
C.1
## Workflow 1. Decide curve type and equation (or browse seed_pool). 2. Pick a specific geometric configuration with concrete numeric values. 3. Call rule_check and/or sympy_check to validate. 4. Call submit_problem with all fields.
Generator
The Generator receives a six-section system prompt covering persona, tools, dual-path strategy, information partition, visual dependency, and workflow.
C.2
Formalizer
The Formalizer employs a seven-layer system prompt: (1) persona, (2) CDL specification (Appendix A), (3) grounding criteria, (4) stepby-step guidance, (5) few-shot examples, (6) output format, and (7) chain-of-thought trigger. When the curve type is detected from the problem text, the CDL specification in Layer 2 is pruned to a grammar subset specific to that curve type, reducing attention dilution. Three examples from a pool of ten are dynamically selected per problem based on curve type.
Generator System Prompt You are a Problem Decomposer for Analytic Geometry. You are an expert math teacher who designs conic section problems. You can freely create problems or draw inspiration from the seed library. You always validate your problems before submitting. ## Your Tools You have five tools at your disposal: - seed_pool: Browse the seed library for reference problems. - enumerate_properties: Given a conic equation, enumerate ALL derivable properties. - sympy_check: Verify that a problem is solvable. - rule_check: Validate problem format. - submit_problem: Submit your finalized problem. You MUST call this tool exactly once when done. Do NOT output raw JSON -- always use the submit_problem tool.
Formalizer System Prompt (Layers 1–4, 6–7) You are an analytic geometry formalization expert. Your task is to convert natural language analytic geometry problems into CDL (Construction Description Language) programs. You are meticulous and never omit geometric objects or relationships.
## Generation Strategies
<cdl_specification> ## CDL Syntax Rules
You may freely choose your approach: 1. Forward: Think of a problem directly, validate with sympy_check and rule_check. 2. Reverse: Browse seed_pool, explore enumerate_properties, compose a new problem. 3. Hybrid: Combine both approaches.
### Declarations Declare geometric objects: NAME: TYPE Supported types: Point, Line, Circle, Ellipse, Hyperbola, Parabola, Curve, Origin, Number, Real One declaration per statement. Separate statements with semicolons. Example: G: Ellipse; P: Point; l: Line; O: Origin
## Information Partition (I_v AND I_t = empty)
### Equations Define curve equations: Equation(NAME) = EXPR = EXPR Use x, y as variables. Use ^ for exponentiation (NOT ). Example: Equation(G) = x^2/9 + y^2/4 = 1
Design problems with TWO types of information: - Text conditions (info_text): Stated explicitly in the problem statement (equation, curve type, named relationships). - Visual conditions (info_visual): Shown only in the diagram, NOT stated in text. These must be CONCRETE and MEASURABLE: specific point coordinates like "(2, 3)", specific slopes like "slope = 1", specific angles like "60 deg", or specific distances.
### Coordinates Assign point coordinates: Coordinate(NAME) = (EXPR, EXPR) Example: Coordinate(P) = (1, 2) ### Predicates Assert geometric relationships (implicitly true): - PointOnCurve(P, G) - IsPerpendicular(l1, l2) - IsParallel(l1, l2) - IsTangent(l, G) - IsChordOf(l, G) - IsDiameter(l, C)
CRITICAL: Visual conditions must be PRECISE NUMERIC VALUES that a vision agent can measure from the rendered diagram. Vague descriptions like "a line through the focus" or "as shown in the figure" are NOT acceptable as visual conditions -- they must specify WHERE the line is (e.g., "the line has slope 2" or "the line passes through (1,3)"). ## Visual Dependency Requirement The problem MUST require reading the diagram to solve. But the diagram must contain MEASURABLE information -- specific coordinates, slopes, angles, or distances that a vision AI can extract. The problem text says "As shown in the figure" and the diagram shows the specific numeric configuration.
### Derived Objects Compute new objects from existing ones: - Focus(G, left/right) - Vertex(G, left/right/upper/lower) - Center(G) - Directrix(G, left/right) - Asymptote(G) - MidPoint(A, B) - Intersection(G1, G2): use {A,B} = Intersection(l,G) for multiple points - TangentOfPoint(P, G) = l - TangentOnPoint(P, G) = l - TangentPoint(l, G) = T - Projection(P, xAxis) = M
### Examples of GOOD problems: - "The ellipse x^2/9+y^2/4=1 has a chord AB through the right focus. Find the perimeter of triangle ABF1." + diagram shows the chord has slope 1. - "Point P is on the parabola y^2=4x. Find |PF|." + diagram shows P at (4, 4). ### Examples of BAD problems:
13
Xu, Gao, and Wang
Formalizer Few-Shot Example 1: Ellipse (PointOnCurve, IsPerpendicular, IsParallel)
- RightPart(G) / LeftPart(G) - OverlappingLine(LineSegmentOf(A, B)) - LineSegmentOf(A, B) - TriangleOf(A, B, C) - VectorOf(A, B) - DotProduct(VectorOf(A,B), VectorOf(C,D)) = value
Problem: The center of the ellipse x^2/a^2 + y^2/b^2 = 1 (a>b>0) is at the origin, F1 and F2 are the left and right foci, A and B are the upper and right vertices, P is a point on the ellipse such that PF1 is perpendicular to the x-axis and PF2 is parallel to AB. Find the eccentricity.
### Metric Constraints - Distance(P, Q) = value - Slope(l) = value - Eccentricity(G) = value - Area(TriangleOf(A, B, C)) = value - FocalLength(G) = value - Inclination(l) = value (radians) - Length(SemiMajorAxis(G)) = value
CDL: G: Ellipse; b: Number; a: Number; a > b; b > 0; O: Origin F1: Point; F2: Point; A: Point; B: Point; P: Point Equation(G) = x^2/a^2 + y^2/b^2 = 1 Center(G) = O Focus(G, left) = F1; Focus(G, right) = F2 Vertex(G, upper) = A; Vertex(G, right) = B PointOnCurve(P, G) IsPerpendicular(LineSegmentOf(P, F1), xAxis) IsParallel(LineSegmentOf(P, F2), LineSegmentOf(A, B))
### Inequality Constraints - a > 0; b > 0; a > b </cdl_specification> <evaluation_criteria> Your CDL output will be evaluated on three dimensions: 1. SYNTAX VALIDITY: Must parse without errors. 2. COMPLETENESS: Every geometric object and relationship mentioned in the problem must appear in CDL. 3. CORRECTNESS: Equations, coordinates, and constraints must accurately reflect the problem.
Formalizer Few-Shot Example 2: Hyperbola + Circle (TangentOfPoint, RightPart, OverlappingLine) Problem: From the left focus F1 of x^2/16 - y^2/25 = 1, draw a tangent to x^2+y^2=16, touching at T. Extend F1T to meet the right branch at P. Let M be the midpoint of F1P. Find |MO| - |MT|.
Common mistakes to avoid: - Missing declarations (every name must be declared with its type) - Wrong equation format (use "Equation(G) = ... = ...", NOT "Expression(G) = (...)") - Omitting PointOnCurve when a point is described as "on the curve" - Using instead of ^ for exponentiation - Including the question/query as a CDL constraint (only encode FACTS, not what is asked) - NEVER use natural language in CDL output - For tangent lines, use TangentOfPoint(P, G) = l (NOT just IsTangent). This creates a Line object that can be rendered - For branches, use RightPart(G) / LeftPart(G) in Intersection - Do NOT invent operators. The following are NOT valid CDL: Vector(...), Triangle(...), Angle(...), LineThrough(...), IsOnAxis(...), CircleWithDiameter(...), Radius(...) </evaluation_criteria>
CDL: G: Hyperbola; H: Circle; F1: Point; Z: Line T: Point; P: Point; M: Point; O: Origin Equation(G) = x^2/16 - y^2/25 = 1 Equation(H) = x^2 + y^2 = 16 Focus(G, left) = F1 TangentOfPoint(F1, H) = Z TangentPoint(Z, H) = T Intersection(OverlappingLine(LineSegmentOf(F1, T)), RightPart(G)) = P MidPoint(LineSegmentOf(F1, P)) = M
Formalizer Few-Shot Example 3: Parabola (Directrix, IsDiameter, Area)
Follow these steps to convert a problem to CDL: Step 1: Identify all curve types. Step 2: Write declarations for all geometric objects. Step 3: Write the equation for each curve. Step 4: Write coordinates for any points with known positions. Step 5: Identify derived objects (foci, vertices, center, directrix, asymptotes, midpoints, intersections). Step 6: Write predicates for geometric relationships. Step 7: Write metric constraints. Step 8: Write inequality constraints if any.
Problem: The parabola C: y^2=2px (p>0) has focus F. A line through F intersects C at A and B. The circle with diameter AB is tangent to the directrix at M(-p/2, 3). Area of triangle AOB = sqrt(13). Find the equation of C. CDL: C: Parabola; p: Number; p > 0; F: Point; O: Origin H: Line; A: Point; B: Point; G: Circle; M: Point Equation(C) = y^2 = 2*p*x Focus(C) = F PointOnCurve(F, H) Intersection(H, C) = {A, B} IsDiameter(LineSegmentOf(A, B), G) Coordinate(M) = (-p/2, 3) TangentPoint(Directrix(C), G) = M Area(TriangleOf(A, O, B)) = sqrt(13)
Do NOT output CDL as raw text. Instead, call the submit_cdl tool with three fields: - declarations: entity declarations - equations: curve equations and inequalities - constraints: everything else (coordinates, derived objects, predicates, metrics) Only encode geometric FACTS stated in the problem. Do NOT encode the question/query part.
The output CDL is immediately parsed by the CDL parser; any syntactic error triggers an automatic retry with the parser’s error message as feedback, before the result reaches the Quality Verifier.
Think step by step before writing CDL.
C.3
Layer 5 provides ten curated few-shot examples covering all four curve types and diverse operator combinations. Three examples are dynamically selected per problem based on the detected curve type. Below we show three representative examples.
Measurer
Task Extractor (Stage 1). The Task Extractor reads only the problem text and outputs a structured measurement instruction. Three critical rules enforce information isolation: no equations, no partial solving, only describe what to measure. 14
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
Task Extractor System Prompt
You will receive a MEASUREMENT INSTRUCTION describing what to measure from a rendered analytic geometry diagram. You do NOT have the original problem text or any equations -- you must measure everything visually.
You are a task decomposition agent for analytic geometry measurement. ## Task
## CRITICAL RULES
Read the problem text and output a JSON object describing what needs to be measured from the rendered diagram. You do NOT measure anything yourself -- you only extract the measurement task.
- You have NO access to curve equations -- measure from the image - Use CV tools for ALL position measurements - You MAY apply basic arithmetic on measured values
## CRITICAL RULES If a quantity cannot be measured (points not visible, line not rendered), output: ANSWER: UNMEASURABLE
- Do NOT include any equation, formula, or coordinate value - Do NOT include curve equations (e.g., x^2/9 + y^2/4 = 1) - Do NOT solve or partially solve the problem - Only describe WHAT to measure and which entities are involved
## Efficiency -- IMPORTANT You have a LIMITED number of tool-call rounds. Be efficient: - Follow the recipe specified in the instruction - Give your ANSWER: as SOON as you have enough measured data - NEVER repeat a tool call with the same arguments
## Output Format Output a single JSON object with these keys: { "task_type": "chord_length", "description": "Measure the length of the chord where line l intersects ellipse C", "entity_names": ["l", "C", "A", "B"], "recipe_name": "chord_length", "entity_hints": {"l": "line", "C": "ellipse", "A": "point", "B": "point"} }
## Measurement Recipes ### Recipe: Eccentricity (ellipse / hyperbola) 1. pixel_to_coord on the RIGHT endpoint along x-axis -> (a, 0) 2. pixel_to_coord on the TOP endpoint along y-axis -> (0, b) 3. Compute: c = sqrt(|a^2 - b^2|), e = c / a 4. ANSWER: e ### Recipe: Chord Length 1. intersect_line_curve(x1, y1, x2, y2) -> P1, P2 2. compute_distance(P1, P2) -> chord length 3. ANSWER: distance
### task_type values One of: eccentricity, chord_length, area, perimeter, slope, distance, radius, focal_length, coordinate, angle, other ### recipe_name values One of: eccentricity, chord_length, area, perimeter, slope, distance, radius, focal_length, other
### Recipe: Area of Triangle 1. Measure all 3 vertex coordinates 2. compute_area(x1,y1, x2,y2, x3,y3) 3. ANSWER: area
### entity_hints Map entity names to their type (line, ellipse, parabola, hyperbola, circle, point, triangle, segment). Do NOT include equations.
### Recipe: Perimeter of Triangle 1. Measure all 3 vertex coordinates 2. compute_distance for each of the 3 sides 3. ANSWER: sum of 3 distances
## Examples ### Recipe: Slope 1. Measure 2 points on the line 2. compute_slope(x1,y1, x2,y2) 3. ANSWER: slope
Problem: "Given ellipse C: x^2/9+y^2/4=1, line l: y=x+1 intersects C at A,B. Find |AB|." Output: { "task_type": "chord_length", "description": "Measure the chord length where line l intersects ellipse C at points A and B", "entity_names": ["l", "C", "A", "B"], "recipe_name": "chord_length", "entity_hints": {"l": "line", "C": "ellipse", "A": "point", "B": "point"} }
### Recipe: Distance Between Two Points 1. Measure both points with pixel_to_coord 2. compute_distance(x1,y1, x2,y2) 3. ANSWER: distance ### Recipe: Radius (circle) 1. Measure center with pixel_to_coord 2. Measure any point on the circle 3. compute_distance(cx,cy, px,py) -> radius 4. ANSWER: radius
Visual Measurer (Stage 2). The Visual Measurer receives only the measurement instruction and the diagram image; it never sees the problem text or equations. The prompt defines eight named measurement recipes, four measurement strategies ranked by preference, and the RAW VALUE RULE defense.
### Recipe: Focus / Focal Length 1. If foci labeled: measure with pixel_to_coord 2. If not: measure a, b, compute c = sqrt(|a^2-b^2|) 3. ANSWER: the requested value ## How to Measure
Visual Measurer System Prompt
### Strategy 1: Line-Curve Intersections (PREFERRED) 1. pixel_to_coord on two points of the line 2. intersect_line_curve(x1, y1, x2, y2)
You are an Analytic Geometry Diagram Visual Measurer. You are a meticulous visual measurement specialist. You extract data by measuring the rendered diagram -- locating points, reading their coordinates, and computing distances/angles from those measurements.
### Strategy 2: Visual Point Location 1. Estimate pixel position from the image 2. pixel_to_coord(px, py) 3. find_nearest_curve_point(x, y) to snap if needed
## Task
15
Xu, Gao, and Wang
Table 10: CV tools available to the Visual Measurer. Because the SDF renderer produces the diagram, viewport metadata is known exactly, eliminating axis-reading errors.
### Strategy 3: Curve Endpoint Measurement 1. pixel_to_coord on rightmost curve point on x-axis -> a 2. pixel_to_coord on topmost curve point on y-axis -> b ### Strategy 4: Curve-Curve Intersections 1. Estimate intersection region visually 2. intersect_curves(x_min, x_max, y_min, y_max)
Tool
## RAW VALUE RULE (MANDATORY -- NEVER VIOLATE)
Coordinate Mapping pixel_to_coord
You MUST report the EXACT numeric values returned by CV tools. Violating any rule below makes the answer INVALID.
coord_to_pixel
1. NEVER round coordinates before passing to compute_* tools: BAD: intersect returns (0.07, -0.01) -> you pass (0, 0) GOOD: intersect returns (0.07, -0.01) -> you pass (0.07, -0.01)
find_nearest_curve_point
2. NEVER round the final answer to a "nicer" number: BAD: compute_distance returns 7.9688 -> you answer 8.0 GOOD: compute_distance returns 7.9688 -> you answer 7.9688
Computation compute_distance
3. NEVER use analytical formulas to override measured values: BAD: measured chord ~ 7.52, but formula gives 8 -> answer 8 GOOD: measured chord ~ 7.52 -> answer 7.52
compute_slope compute_angle
4. ALWAYS use compute_* tools for the final numeric result: For distance -> call compute_distance, report its result For area -> call compute_area, report its result NEVER compute these mentally or with formulas
compute_area
Your ANSWER value must be DIRECTLY TRACEABLE to a compute_* tool output. If no compute_* tool was called, your answer is invalid.
Scanning scan_region
## Output Format
profile_line
ANSWER: <value> - Number: ANSWER: 7.9688 - Coordinate: ANSWER: (3.0137, 4.0059) - Unmeasurable: ANSWER: UNMEASURABLE
Intersection intersect_line_curve intersect_curves
CV tool suite. Table 10 lists the twelve computer-vision tools available to the Visual Measurer, organized into four categories. Curve pixels are identified by HSV saturation filtering (curves are rendered in saturated colors; axes and text are black).
C.4
verify_point_on_curve
Quality Verifier
Description Convert pixel position to data coordinates via the known affine transform Convert data position to pixel coordinates Snap a query point to the nearest curve pixel using HSV saturation filtering Euclidean distance between two data-coordinate points Slope of the line through two points Angle at a vertex from three points (degrees) Polygon area via the Shoelace formula Detect curve pixels within a rectangular bounding box Find curve crossings along a horizontal or vertical scan line Compute line–curve intersection points via scan-line refinement Compute curve–curve intersections within a region Check whether a point lies on a given curve within tolerance
2. Assess problem quality: Is the question clear? Is the equation consistent with the stated curve type? 3. Check for degenerate cases (e.g., eccentricity asked for a circle = always 0).
The Quality Verifier shares a single prompt across all three gates; only the available tool subset changes per gate.
IMPORTANT for Gate 1: These problems are designed to be DIAGRAM-DEPENDENT. The problem will be accompanied by a rendered diagram, so it is EXPECTED and ACCEPTABLE for some geometric elements to be defined visually in the diagram rather than algebraically in the text. Do NOT reject a problem just because a line, point, or geometric relationship is not fully specified in the text -- this is BY DESIGN. Only reject if: - The equation itself is invalid or inconsistent - The question is completely unclear or nonsensical - The problem is trivially degenerate
Quality Verifier System Prompt You are an Analytic Geometry Quality Reviewer. You are a meticulous reviewer who never trusts outputs at face value. You systematically verify mathematical solvability, annotation completeness, and measurement accuracy using independent tools. You provide clear, actionable feedback when issues are found. ## Task
### Gate 2 -- CDL Annotation Review You receive: problem_text, equation, cdl_text. Your checks: 1. Call validate_cdl_syntax to verify CDL parses correctly. 2. Call check_cdl_completeness to get NL<->CDL entity comparison. 3. Using the completeness report, judge whether: - All geometric objects have CDL declarations - All relationships have CDL predicates - The equation in CDL matches the problem's equation - No extraneous or contradictory annotations exist
You are an independent reviewer in an analytic geometry data generation pipeline. At each gate, you receive the output of a pipeline stage and must verify its quality using the provided tools. Your judgment determines whether the output passes to the next stage or is sent back for revision. ## Verification Protocol ### Gate 1 -- Problem Generation Review You receive: problem_text, equation, curve_type, goal_type. Your checks: 1. Call verify_solvability to confirm the equation is valid.
IMPORTANT for Gate 2: CDL does NOT contain "Goal" or objective
16
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
statements. The problem's goal is tracked externally via a goal_type field, NOT inside the CDL annotation. Do NOT reject a CDL annotation for missing a Goal/objective predicate.
""" # ===== Computation =====
### Gate 3 -- Answer Verification Review You receive: problem_text, equation, agent3_answer, metric_type. Your checks: 1. Call check_answer_range to verify valid bounds. 2. Call solve_text_only to compute an independent analytical answer. 3. Compare Agent 3's visual measurement with the analytical solution: - If relative error <= 5%: PASS (answers agree) - If 5% < relative error <= 20%: WARN (flag but pass) - If relative error > 20%: FAIL (significant disagreement) - If analytical solution unavailable: rely on range check only
def compute_distance( x1: float, y1: float, x2: float, y2: float ) -> dict: """Compute the Euclidean distance between two points in data coordinates. Returns: {"distance": float} """ def compute_slope( x1: float, y1: float, x2: float, y2: float ) -> dict: """Compute the slope between two points.
## Output Format After running your checks, output your verdict as JSON: { "gate": 1|2|3, "passed": true|false, "confidence": 0.0-1.0, "checks": [ {"name": "check_name", "passed": true|false, "detail": "..."} ], "feedback": "Actionable feedback for the upstream agent (empty string if passed)" }
Returns: {"slope": float} or {"slope": "undefined"} for vertical """ def compute_angle( x1: float, y1: float, vx: float, vy: float, x2: float, y2: float ) -> dict: """Compute the angle at vertex (vx, vy) formed by points (x1, y1) and (x2, y2), in degrees.
IMPORTANT: - Be SKEPTICAL. Do not assume correctness without evidence. - Provide SPECIFIC feedback. Not "CDL is incomplete" but "Missing PointOnCurve(P, G) -- the problem states P is on the ellipse but CDL has no such predicate." - Use tools before judging. Do not skip tool calls. - Output ONLY the JSON verdict after completing your checks.
C.5
Returns: {"angle_degrees": float} """ def compute_area( points: list[dict] ) -> dict: """Compute polygon area using the Shoelace formula. Points should be in order (CW or CCW).
CV Tool Definitions
The following are the Python-based tool definitions available to the Visual Measurer, along with their inputs, outputs, and expected behaviors. Curve pixels are identified by HSV saturation filtering (curves are rendered in saturated colors; axes and text are black). All coordinate conversions use the viewport metadata produced by the SDF renderer.
Args: points: [{"x": float, "y": float}, ...] Returns: {"area": float} """ # ===== Scanning ===== def scan_region( x_min: float, x_max: float, y_min: float, y_max: float, max_points: int = 200 ) -> dict: """Scan a rectangular region and return all curve pixel coordinates. Useful for understanding curve distribution in a region.
CV Tool Definitions # ===== Coordinate Mapping ===== def pixel_to_coord(px: int, py: int) -> dict: """Convert pixel coordinates to data coordinates using viewport metadata. Returns: {"x": float, "y": float} """
Returns: {"curve_pixels": [{"x", "y"}, ...], "count": int} """
def coord_to_pixel(x: float, y: float) -> dict: """Convert data coordinates to pixel coordinates.
def profile_line( x1: float, y1: float, x2: float, y2: float, n_samples: int = 200 ) -> dict: """Sample pixels along a line segment and find where curves cross it.
Returns: {"px": int, "py": int} """ def find_nearest_curve_point( x: float, y: float, search_radius: int = 50 ) -> dict: """Find the nearest curve pixel to a given data coordinate. Useful for refining approximate coordinates to snap to the actual curve.
Returns: {"crossings": [{"x", "y", "index"}, ...], "count": int} """ # ===== Intersection =====
Returns: {"x": float, "y": float, "pixel_distance": float}
17
Xu, Gao, and Wang
D
def intersect_line_curve( x1: float, y1: float, x2: float, y2: float, n_samples: int = 500 ) -> dict: """Find all intersection points between a line (defined by two points) and the rendered curves. Automatically extends the line to viewport bounds and refines each crossing via nearest-curve-point snapping. Best tool for line-curve intersections.
Additional Generated Examples
This appendix presents four examples that illustrate how CDL encodes multi-curve analytic-geometry configurations and how the SDF engine renders them. Every diagram contains two distinct conic or circle types, together with auxiliary lines and labelled points. Table 11 summarises the geometric complexity of each example. Table 11: Geometric complexity of the four examples. Every diagram contains two distinct curve primitives.
Returns: {"intersections": [{"x", "y"}, ...], "count": int} """
Example def intersect_curves( x_min: float, x_max: float, y_min: float, y_max: float ) -> dict: """Find intersection points of multiple rendered curves within a bounding box. Scans for dense clusters of curve pixels where multiple branches overlap. Useful for curve-curve crossings (e.g., ellipse and circle, parabola and circle).
Confocal (D.1) Parab.+Circle (D.2) Auxiliary (D.3) Hyp.+Circle (D.4)
D.1
Returns: {"intersections": [{"x", "y"}, ...], "count": int} """
Curve types
Lines
Points
CDL
Ellipse + Hyperbola Parabola + Circle Ellipse + Circle Hyperbola + Circle
1 1 1 2
6 5 6 6
10 9 9 12
Confocal Ellipse and Hyperbola 2
𝑦2
2
𝑦2
“The ellipse 𝑥25 + 9 = 1 and the hyperbola 𝑥4 − 12 = 1 are confocal, sharing foci 𝐹 1 and 𝐹 2 . They intersect at 𝐴 and 𝐵 in the right half-plane. A tangent to the ellipse at 𝐴 meets the 𝑥-axis at 𝑇 . Find the area of △𝐹 1𝐴𝐹 2 .”
def verify_point_on_curve( x: float, y: float, equation_str: str ) -> dict: """Verify if a point lies on a curve by substituting into the equation and checking residual.
E: Ellipse; H: Hyperbola; F1: Point; F2: Point A: Point; B: Point; l: Line; T: Point; O: Origin Equation(E) = x^2/25 + y^2/9 = 1 Equation(H) = x^2/4 - y^2/12 = 1 Focus(E, left) = F1; Focus(E, right) = F2 Coordinate(A) = (2.5, 2.598) Coordinate(B) = (2.5, -2.598) PointOnCurve(A, E); PointOnCurve(B, E) TangentOnPoint(A, E) = l Intersection(l, xAxis) = T
Args: equation_str: e.g. "x**2/9 + y**2/4 = 1" Returns: {"on_curve": bool, "residual": float} """
√ Analytical ground truth: Area = 6 3 ≈ 10.3923. Measurer answer: 10.3528 (relative error 0.38%). The Measurer locates 𝐹 1 and 𝐹 2 via pixel_to_coord at the labelled foci, measures 𝐴 at (2.496, 2.594), and calls compute_area on√the three√vertices. Both conics share foci at (±4, 0) (since 𝑐 = √25 − 9 = 4 + 12 = 4). Their four intersection points lie at (±2.5, ± 3 2 3 ); confocal conics meet at right angles. The CDL declares both an Ellipse and a Hyperbola, and uses a cross-curve TangentOnPoint construction.
D.2
Upward Parabola and Circle “The parabola 𝑥 2 = 4𝑦 has focus 𝐹 and directrix 𝑦 = −1. A circle centred at 𝑀 (0, 3) with radius 3 intersects the parabola at 𝐴 and 𝐵. Find the distance |𝐴𝐵|.”
G: Parabola; C: Circle; F: Point; M: Point A: Point; B: Point; ld: Line; O: Origin Equation(G) = x^2 = 4*y Equation(C) = x^2 + (y-3)^2 = 9 18
FormalAnalyticGeo: A Neural-Symbolic Based Framework for Multimodal Analytic Geometry Problem Generation
D.3
Ellipse and Auxiliary Circle 2
𝑦2
“The ellipse 𝑥16 + 9 = 1 and its auxiliary circle 𝑥 2 + 𝑦 2 = 16 share centre 𝑂. The ellipse has foci 𝐹 1 and 𝐹 2 . A tangent to the ellipse at 𝑃 (2, 2.598) intersects the auxiliary circle at 𝐴 and 𝐵. Find the area of △𝐹 1 𝑃𝐹 2 .”
E: Ellipse; C: Circle; P: Point; l: Line A: Point; B: Point; O: Origin; F1: Point; F2: Point Equation(E) = x^2/16 + y^2/9 = 1 Equation(C) = x^2 + y^2 = 16 Focus(E, left) = F1; Focus(E, right) = F2 Coordinate(P) = (2, 2.598) PointOnCurve(P, E) TangentOnPoint(P, E) = l Intersection(l, C) = {A, B}
Figure 5: Confocal ellipse (blue) and hyperbola (red) with shared foci, tangent at 𝐴.
√
Analytical ground truth: Area = 3 221 ≈ 6.8738. Measurer answer: 6.8492 (relative error 0.36%). The Measurer measures 𝐹 1 at (−2.644, 0.003) and 𝐹 2 at (2.641, −0.002) via pixel_to_coord, reads 𝑃 at (1.998, 2.595), and calls compute_area on the triangle. The auxiliary circle 𝑥 2 + 𝑦 2 = 𝑎 2 circumscribes the ellipse along the major axis. The Intersection operates across two curve types: the tangent to the ellipse is intersected with the circle.
Focus(G) = F; Center(C) = M Coordinate(A) = (2.828, 2) Coordinate(B) = (-2.828, 2) PointOnCurve(A, G); PointOnCurve(B, G) Equation(ld) = y = -1
√ Analytical ground truth: Distance = 4 2 ≈ 5.6569. Measurer answer: 5.6437 (relative error 0.23%). The Measurer uses intersect_curves to locate the two parabola–circle crossings at (2.824, 1.997) and (−2.831, 2.003), then calls compute_distance on the pair. The circle and parabola intersect where 𝑥 2 + (𝑦 − 3) 2 = 9 and 2 𝑥 = 4𝑦, √ giving 𝑦 (𝑦 − 2) = 0; the non-trivial root 𝑦 = 2 yields 𝐴 and 𝐵 at (±2 2, 2). The directrix 𝑦 = −1 is rendered as an additional horizontal line.
Figure 7: Ellipse (blue) inscribed in auxiliary circle (magenta), with cross-curve tangent.
D.4
Hyperbola and Circle with Asymptotes 2
“The hyperbola 𝑥4 − 𝑦 2 = 1 has vertex 𝑉 , foci 𝐹 1 , 𝐹 2 , and asymptotes 𝑦 = ± 𝑥2 . The circle 𝑥 2 + 𝑦 2 = 9 intersects the right branch at 𝐴 and 𝐵. Find the length |𝐴𝐵|.”
Figure 6: Upward parabola (green) and circle (magenta), with directrix and intersection points.
H: Hyperbola; C: Circle; V: Point; F1: Point F2: Point; a1: Line; a2: Line 19
Xu, Gao, and Wang
A: Point; B: Point; O: Origin Equation(H) = x^2/4 - y^2 = 1 Equation(C) = x^2 + y^2 = 9 Vertex(H, right) = V Focus(H, left) = F1; Focus(H, right) = F2 Equation(a1) = y = 0.5*x Equation(a2) = y = -0.5*x Coordinate(A) = (2.828, 1) Coordinate(B) = (2.828, -1) PointOnCurve(A, H); PointOnCurve(B, H)
Analytical ground truth: |𝐴𝐵| = 2. Measurer answer: 1.9963 (relative error 0.19%). The Measurer uses intersect_curves in the right half-plane to locate 𝐴 at (2.831, 0.999) and 𝐵 at (2.827, −0.997), then calls compute_distance. This is the most element-rich example: a Hyperbola (both branches), a Circle, two asymptote lines, a vertex, and both foci—12 CDL statements producing 6 labelled points alongside two curves.
20
Figure 8: Hyperbola (red) and circle (magenta) with asymptotes, foci, and vertex.