Paper deep dive

Synthesizing Multimodal Geometry Datasets from Scratch and Enabling Visual Alignment via Plotting Code

Haobo Lin, Tianyi Bai, Chen Chen, Jiajun Zhang, Bohan Zeng, Wentao Zhang, Binhang Yuan

Year: 2026Venue: arXiv preprintArea: cs.CVType: PreprintEmbeddings: 146

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%

Last extracted: 7/20/2026, 9:26:29 PM

Summary

The paper introduces GeoCode, a pipeline for synthesizing complex multimodal geometry datasets from scratch. It decouples problem generation into symbolic seed construction, grounded instantiation with verification, and code-based diagram rendering. The dataset, GeoCode, includes 18K problems with high structural complexity and reasoning difficulty. A key contribution is using plotting code as an explicit alignment objective to transform visual understanding into a supervised structured prediction task, improving model performance on geometry benchmarks.

Entities (5)

GeoCode · dataset · 98%Vision-Language Models · model-class · 95%Plotting Code · data-modalityrepresentation · 92%AlphaGeometry · softwaremodel · 90%Multimodal Geometry Reasoning · task · 90%

Relation Signals (5)

GeoCode → contains → Plotting Code

confidence 95% · Leveraging the plotting code provided in GeoCode...

Plotting Code → enables → Visual Alignment

confidence 92% · Leveraging the plotting code provided in GeoCode, we further introduce code prediction as an explicit alignment objective

GeoCode → improvesperformanceon → Geometry Benchmarks

confidence 90% · models trained on GeoCode achieve consistent improvements on multiple geometry benchmarks

GeoCode → synthesizedby → Pipeline

confidence 90% · We propose a pipeline for synthesizing complex multimodal geometry problems from scratch and construct a dataset named GeoCode

AlphaGeometry → usedfor → Symbolic Seed Construction

confidence 85% · symbolic geometric seeds constructed via dependency analysis using systems such as AlphaGeometry

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Multimodal geometry reasoning requires models to jointly understand visual diagrams and perform structured symbolic inference, yet current vision--language models struggle with complex geometric constructions due to limited training data and weak visual--symbolic alignment. We propose a pipeline for synthesizing complex multimodal geometry problems from scratch and construct a dataset named \textbf{GeoCode}, which decouples problem generation into symbolic seed construction, grounded instantiation with verification, and code-based diagram rendering, ensuring consistency across structure, text, reasoning, and images. Leveraging the plotting code provided in GeoCode, we further introduce code prediction as an explicit alignment objective, transforming visual understanding into a supervised structured prediction task. GeoCode exhibits substantially higher structural complexity and reasoning difficulty than existing benchmarks, while maintaining mathematical correctness through multi-stage validation. Extensive experiments show that models trained on GeoCode achieve consistent improvements on multiple geometry benchmarks, demonstrating both the effectiveness of the dataset and the proposed alignment strategy. The code will be available at this https URL.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

144,887 characters extracted from source content.

Expand or collapse full text

Synthesizing Multimodal Geometry Datasets from Scratch and Enabling Visual Alignment via Plotting Code Haobo Lin 1,2,∗ , Tianyi Bai 1,∗,‡ , Chen Chen 2 , Jiajun Zhang 3 Bohan Zeng 4 , Wentao Zhang 4 , Binhang Yuan 1,† 1 HKUST, 2 JLU 3 USTC, 4 PKU, ∗ Equal contribution, † Corresponding author, ‡ Project leader Abstract Multimodal geometry reasoning requires models to jointly understand visual diagrams and perform structured symbolic inference, yet current vision–language models struggle with complex geometric constructions due to limited training data and weak visual–symbolic alignment. We propose a pipeline for synthesizing complex multimodal geometry problems from scratch and construct a dataset named GeoCode, which decouples problem generation into symbolic seed construction, grounded instantiation with verification, and code-based diagram rendering, ensuring consistency across structure, text, reasoning, and images. Leveraging the plotting code provided in GeoCode, we further introduce code prediction as an explicit alignment objective, transforming visual understanding into a supervised structured prediction task. GeoCode exhibits substantially higher structural complexity and reasoning difficulty than existing benchmarks, while maintaining mathematical correctness through multi- stage validation. Extensive experiments show that models trained on GeoCode achieve consistent improvements on multiple geometry benchmarks, demonstrating both the effectiveness of the dataset and the proposed alignment strategy. The code will be available athttps://github.com/would1920/ GeoCode. 1 Introduction Geometry reasoning has long been regarded as a core testbed for multimodal intelligence. Unlike natural image understanding or general visual question answering, geometry problems require precise visual perception, structured symbolic representations, and multi-step logical reasoning to jointly support a verifiable conclusion. [1–4] Recent advances in vision–language models (VLMs)[5–12] have led to notable progress on basic geometry-related benchmarks[13–18]. However, when faced with problems involving complex constructions, dense relational constraints, and long-chain reasoning, current models still exhibit substantial limitations, particularly in their ability to recover geometric structure from diagrams and to maintain consistency across intermediate reasoning steps[1, 17, 18]. From a problem-solving perspective, multimodal geometry reasoning is commonly decomposed into two stages: (1) visual–symbolic alignment, which recovers structured geometric entities and relational constraints from diagrams, and (2) symbolic reasoning, which performs deductive inference under joint visual and textual conditions. Recent advances in formal geometry solvers show that, when accurate symbolic representations are available, purely symbolic systems can solve problems approaching International Mathematical Olympiad (IMO) level without any visual input [19,20], indicating that long-horizon geometric deduction itself is largely tractable. In contrast, multimodal models must additionally infer symbolic structure from visual diagrams, 1 arXiv:2602.18745v1 [cs.CV] 21 Feb 2026 Diagram Alignment Representation Reasoning Answer Code-Based Alignment Align to constructions Explicit structural relations Programmatically grounded Implicit/Text Alignment Align to words, not structure Geometry remains latent Hard to recover relations Lack of High-quality Data Manually/template-based Simple constructions Few long-chain reasoning From the geometry shown in the figure, points H, I, and B are collinear.There is a straight line segment connecting H and B, and point Ilies on this segment, so H–I– B are on the same line. Data Alignment Figure 1 Motivation of our work. We address the limitations of implicit visual–symbolic alignment and low structural diversity and low problem difficulty in current geometry datasets by synthesizing problems from scratch and supervising models with plotting code for explicit structural grounding. and empirical evaluations on geometry benchmarks reveal persistent failures in robust structure recovery and intermediate-step consistency under complex constructions and dense relational constraints [16–18]. This suggests that the dominant bottleneck lies in converting visual layouts into faithful symbolic representations rather than in downstream logical inference. Existing methods attempt to mitigate this gap through improved vision–language alignment [21,22], synthetic data generation with reasoning supervision [23–25], or solver-driven pipelines that ensure symbolic correctness [26,27], achieving notable progress on standard benchmarks. Nevertheless, two limitations remain: most datasets are generated via manual design or limited symbolic sampling, resulting in restricted structural diversity and insufficient reasoning depth, and alignment is typically supervised only at the level of answers or natural-language reasoning, leaving geometric structure recovery from diagrams weakly constrained and largely implicit. Consequently, models may rely on linguistic correlations or dataset biases rather than explicitly reconstructing geometric relations from visual input. Unlike general multimodal reasoning tasks [28], geometry possesses a distinctive advantage: its structures are both symbolically solvable and numerically verifiable via coordinate-based constructions, enabling strict validation of geometric consistency. This property makes it feasible to synthesize geometry problems from scratch with correctness guarantees and to enforce cross-modal consistency among symbolic structures, language, reasoning traces, and rendered diagrams, an opportunity that remains underexploited in existing multimodal geometry datasets. Motivated by this observation, we propose a pipeline for synthesizing multimodal geometry problems from scratch, and construct a dataset named GeoCode. Our pipeline begins with symbolic geometric seeds constructed via dependency analysis using systems such as AlphaGeometry, ensuring that each seed admits non-trivial deductive targets at the symbolic level. These structures are then instantiated by large language models, which propose concrete numerical parameters, natural language problem statements, and reasoning traces. To ground these textual specifications into explicit geometric configurations, a separate Coder module generates meta code that constructs coordinate-level realizations of all geometric entities. Finally, we perform strict semantic and geometric validation, together with visual quality filtering, to discard inconsistent or ill-posed samples. As a result, each retained instance maintains strict consistency across symbolic structure, textual description, reasoning process, and visual representation. 2 Beyond data generation, the availability of plotting code in GeoCode further enables a new alignment paradigm based on code-supervised diagram understanding. Instead of supervising models only with answers or textual reasoning, we introduce plotting code as an explicit supervision target. Predicting plotting code requires models to reconstruct the full geometric structure from images, including construction dependencies and spatial relations, effectively converting visual understanding into a structured and verifiable prediction task. This design makes geometric perception an explicit and supervised component of the learning objective, rather than an implicit latent representation. Extensive experiments demonstrate that our synthesized dataset exhibits higher structural complexity and reasoning difficulty than existing geometry benchmarks, and that models trained on our data achieve consistent improvements across multiple public geometry datasets, also under out-of-distribution evaluation. Ablation studies further confirm the critical role of plotting-code supervision in strengthening visual–symbolic alignment, showing clear advantages over text-only alignment. We argue that geometric diagrams are inherently complete and representations of structure, whereas language is unavoidably lossy and ambiguous; therefore, effective geometry reasoning should be grounded in explicit structural representations rather than relying solely on linguistic supervision. The main contributions of this work are summarized as follows: •We propose a pipeline to synthesize multimodal geometry problems from scratch, with verification across symbolic structure, language description, reasoning trace, and visual diagram. •We construct GeoCode, an 18K multimodal geometry dataset with diagrams, solutions, and plotting code, while achieving significantly higher difficulty and structural complexity under strict correctness. •We introduce plotting code as an explicit supervision target for cross-modal alignment, enabling struc- tured learning of geometric relations from visual diagrams. •We show consistent improvements on multiple public geometry benchmarks, including in out-of- distribution settings. 2 Related Work Multimodal Large Language Models and Reasoning Recent years have witnessed rapid advances in large language models (LLMs), leading to strong performance across a wide range of reasoning tasks. The introduction of GPT-4[29] and subsequent vision–language models[8] has further shifted the community’s focus toward multimodal understanding[10,11,30], where extracting and integrating visual information becomes an essential capability. To enhance reasoning, many works adopt explicit intermediate supervision such as Chain- of-Thought (CoT)[31], enabling models to generate multi-step reasoning traces. More recently, reinforcement learning based alignment methods, including PPO[32] and GRPO[33], have been widely applied to further optimize reasoning behaviors under task-specific objectives or preference feedback, yielding consistent improvements on complex reasoning benchmarks. Multimodal Geometry Problem Solving. Geometry problem solving is a challenging multimodal task that requires jointly understanding visual diagrams and performing structured symbolic reasoning. With the development of multimodal LLMs, MGPS has become an important testbed for evaluating visual–symbolic reasoning. Existing approaches mainly fall into three categories: alignment-oriented methods such as EAGLE[21] and MAVIS[22] that enhance visual perception via staged vision–language alignment, data-centric methods such as R-CoT[24], G-LLaVA[23], and MathCoder-VL[25] that construct synthetic multimodal training data with reasoning traces, and solver-driven generation methods that leverage symbolic geometry solvers such as AlphaGeometry[19], with representative works including GeoGen[26] and TrustGeoGen[27]. However, two fundamental challenges remain.First, the lack of large-scale, high-quality geometry datasets with sufficient structural complexity and strict cross-modal consistency limits models’ ability to learn long-range geometric dependencies and multi-step reasoning patterns.Second, effective visual–symbolic alignment mechanisms are still underexplored, as most methods supervise only final answers or textual reasoning without explicitly constraining geometric structure reconstruction from diagrams. 3 Random Sampling Target Finder Filter & Selection Template Translation Filtering & Sort Subgoals Extraction Seed Data a : ; b : ; c : perp a b a c, conga b a c; d : conga d b c, conga b c d; e : perp c d de; f : perp d e ef, congd e ef; g : para d e f g, para d g e f; Seed Data Numerical Q&A Meta Code Semantic Validity Instructor Coder Meta Code Problem: Construct point A. Construct point B. Construct point C, AB and AC are parallel Solution:No auxiliary points. Because ..., Then Because..., Then because..., Finally we get △퐴퐵퐻∼△퐹퐵퐺. Conclusion: △퐴퐵퐻∼△퐹퐵퐺 Problem, Solution, Conclusion Problem: In Triangle ABC, AB=3 ... Find Area of BCD. CoT: Step1: ...; Step 2: ...; Step 3: ...; Answer: 5/ Q.E.D def get_point_coordinates(): A = (0, 0) ... D= ((A[0] + C[0]) / 2, (A[1] + C[1]) / 2) def get_plotting_code(): ... Answer Correctness Coordinate Matching Geometric Plausibility Logical Consistency Numerical Verifier Plotting Code "points“: [...] “segments”: [...] "circles": [...] "annotations“: ... Passed Diagram Numerical Q&A Quality Checker Text Debias Image: figure0.png Problem: Find the length of CD. Plotting Code: "points“: [...], “segments”: [...], "circles": [...] , "annotations“: ... CoT: Step1. From the image, read ∠BAC=30...Step2. ...using the visible label AB=10, infer AC=10...Step4. Apply the Law of Sines...gives 퐶퐷=10√3−10 Answer: 10√3−10 Sampling Stage 1. Seed Generation Stage 2. Instantiation Stage 3. Visualization Premises, Steps and Targets Predicates Dependency Graph P P P P P S S S P S S S T Generated Data Diagrams Solution / Proof Figure 2 Overview of the data generation pipeline. Our framework factorizes synthesis into three verifiable stages: (1) Seed Generation for symbolic relational structures, (2) Instantiation for numerical grounding and meta-code generation, and (3) Visualization for diagram rendering and textual debiasing. 3 Method In this section, we present a generation pipeline for synthesizing complex multimodal geometry problems from scratch. We first construct symbolic geometric structures and instantiate them with concrete metrics, and then render them into visual diagrams to ensure strict cross-modal consistency in Section 3.1. Building on this pipeline, we further introduce plotting code as an explicit alignment target in Section 3.2, which supervises models to recover geometric structure directly from diagrams. 3.1 Generation Pipeline As illustrated in Fig. 2, our generation pipeline factorizes multimodal geometry problem synthesis into three modular and verifiable stages: (i) symbolic seed generation for constructing relational structures, (i) grounded instantiation with semantic and geometric verification, and (i) visualization with textual debiasing. This decomposition disentangles logical structure, metric realization, and perceptual presentation, enabling controllable synthesis while maintaining strict cross-modal alignment. 3.1.1 Seed Generation This stage focuses on constructing symbolic geometric structures without numerical grounding or linguistic formulation. While random sampling and theorem provers are effective at exploring and validating relational configurations, assigning metric values that both satisfy constraints and yield pedagogically meaningful problems is considerably more difficult and error prone. We therefore decouple structural discovery from metric instantiation, and restrict this stage to symbolic reasoning over geometric predicates. Seed generation starts from random sampling of predicate sets, which specify relations such as incidence, parallelism, perpendicularity, and equality among abstract geometric entities. These sampled predicates form candidate relational graphs, serving as hypotheses in the symbolic space. 4 Target Finder via Dependency Construction. Given a predicate setSand a theorem libraryT, we apply forward symbolic reasoning to derive all propositions that are logically implied by S: D(S) =p| S ⊢ T p. AlphaGeometry is used as the reasoning engine to construct dependency graphs, where nodes correspond to predicates and edges encode proof dependencies. Each valid reasoning target is associated with a proof graph consisting of premises, intermediate steps, and a final conclusion. This process determines whether the sampled structure admits non-trivial deductive chains rather than isolated or redundant constraints. Filter and Selection. Due to the stochastic nature of predicate sampling, many derived configurations are trivial, degenerate, or pedagogically uninformative. We first discard cases that reduce to tautological or equivalent propositions. For the remaining candidates, we characterize symbolic complexity using two complementary measures: the number of premises, reflecting structural breadth, and the number of proof steps, reflecting deductive depth. We rank all candidates by each measure separately, retain the topρpercentile under both rankings, and take their intersection as the final seed set. This strategy biases selection toward problems that are simultaneously structurally rich and reasoning-intensive in the symbolic space. After template-based translation, each retained configuration is represented as Seed Data consisting of (i) symbolic premises, (i) ordered proof steps, and (i) target conclusions. Notably, these seeds specify only geometric structure and logical relations, and contain no numerical values or coordinate information. They define abstract problem skeletons that will be grounded and verified in the subsequent instantiation stage. 3.1.2 Instantiation This stage maps abstract symbolic seeds into fully specified geometry problems with numerical grounding, natural language formulation, geometric constructions, and verified answers. Concretely, instantiation produces problem statements, reasoning traces, final answers, and geometric construction programs that together define a complete problem instance. To achieve this, we decompose instantiation into three functional components: an Instructor for problem realization, a Coder for geometric construction, and a two-stage verification mechanism for correctness control. Instructor for Numerical Grounding and Reasoning Generation. Given Seed Data consisting of symbolic premises, proof structures, and target conclusions, we employ a reasoning-oriented language model as an Instructor to generate instantiated geometry problems. The Instructor assigns concrete numerical values that satisfy all symbolic constraints (e.g., selecting Pythagorean triples for right triangles), translates formal predicates into natural language problem statements, and produces ordered reasoning traces together with final answers. This process transforms abstract relational structures into solvable and pedagogically meaningful geometry questions while preserving all logical dependencies encoded in the seed. Coder for Geometric Construction. For each instantiated problem, we further generate geometric meta code using a separate Coder model. Conditioned only on the problem statement, the Coder predicts a set of executable construction functions that compute coordinates of geometric entities through numerical and geometric computations. These functions are executed in a sandbox environment and are parsed to recover two types of information: (i) concrete coordinates of all points, and (i) structured drawing information, such as which points are connected by segments, which circles are drawn, and what symbolic annotations are present. By executing and parsing these construction functions, we obtain a complete geometric scene specification that supports both numerical verification and deterministic visualization. Importantly, the Coder does not receive the reasoning trace or the final answer as input, preventing leakage of solution information into the geometric construction process. This ensures that all geometric realizations are grounded solely in the textual problem description. Two-stage Verification. To ensure correctness and consistency across modalities, we perform verification at both semantic and geometric levels. (1) Semantic validation. An independent language model evaluates 5 ProblemPlotting CodeDiagram Render Inference ProblemPlotting CodeDiagram Align Understand Problem: Given points (A) and (E) such that (AE = 14). With center (E) and radius (6), draw a circle and choose points (C, F, H) on the circle so that (CE = EF = EH = 6); with center (A) and radius (10), draw another circle and choose points (D, G, I) on the circle so that (AD = AG = AI = 10). It is given that (EF FG) and (AG FG), and that (EH HI) and (AI HI); therefore, lines (FG) and (HI) are the common external tangents of the two circles, tangent to the circles at points (F, G) and (H, I), respectively. Let (B) be the intersection point of lines (AE) and (FH). Point (J) lies on line (AE) such that (BJ = 5), and point (K) lies on the extension of line (FH) such that (BK = 12). Plotting Code: "points": "A": [507, 364], "B": [116, 364], "C": [308, 364], "D": [756, 364], "E": [159, 364], "F": [116, 221], "G": [436, 126], "H": [116, 507], "I": [436, 603], "J": [240, 364], "K": [116, 65], "segments": [["A", "E"], ["C", "E"], ["E", "F"], ["E", "H"], ["A", "D"], ["A", "G"], ["A", "I"], ["F", "G"], ["H", "I"], ["F", "H"], ["B", "J"], ["B", "K"], ["J", "K"]], "circles": [["C1", "E“, “6”], ["C2", "A“, “10”]], "annotations": "right_angles": [["E", "F", "G"], ["A", "G", "F"], ["E", "H", "I"], ["A", "I", "H"]], "length_of_line": [[["E", "F"], "6"], [["E", "H"], "6"], [["A", "D"], "10"], [["A", "G"], "10"], [["A", "I"], "10"]], "measure_of_angle": [] Render Align Inference Understand Given that AE equals 14 and CE equals 6, therefore FG and HI are common external tangents to the two circles. Point J satisfies BJ equals 5, and point K satisfies BK equals 12.Find the length of JK. Figure 3 Plotting code as explicit alignment. Instead of relying on lossy linguistic descriptions, we utilize structured plotting code as an intermediate representation to couple visual perception with symbolic reasoning. whether the problem statement is logically coherent, whether the generated reasoning trace follows from the premises, and whether the stated answer is consistent with the reasoning. (2) Geometric validation. Using coordinates produced by executing the meta code, we numerically verify all declared constraints, including lengths, angles, parallelism, and perpendicularity, as well as the final answer when it involves metric quantities. Samples that violate any semantic or geometric condition are discarded. 3.1.3 Visualization This stage transforms geometric constructions into visual diagrams and removes textual shortcuts that may undermine genuine multimodal reasoning. It consists of two components: diagram rendering based on plotting code, and textual debiasing that enforces reliance on visual information. Diagram Rendering. By executing and parsing the meta code, we obtain structured plotting code, including point coordinates and drawing specifications such as segments, circles, and annotations. Using these two types of information, we render geometry diagrams with OpenCV, following standard textbook-style conventions to produce clean and unambiguous figures. In practice, we observe that certain constructions may lead to severe visual overlap or near-degenerate layouts that hinder perception. We therefore perform image-level quality checks and discard samples with excessive overlaps or ambiguous configurations, ensuring that retained diagrams are visually interpretable and suitable for learning. Textual Debiasing. Previous studies have shown that models can achieve non-trivial performance on geometry tasks using text alone[18], suggesting that textual descriptions may act as shortcuts that bypass visual reasoning. Such behavior contradicts the goal of multimodal geometry understanding. To mitigate this issue, 6 a : ; b : ; c : perp a c b c ; d e : coll b c d, coll b c e, cong c d d e, cong b e d e ; f : perp b f c f, para a e b f Construct point A. Construct point B. Construct point C such that AC is perpendicular to BC. Construct points D and E such that points B, C, and D are collinear, points B, C, and E are collinear, CD equals DE, and BE equals DE. Construct point F such that BF is perpendicular to CF and AE is parallel to BF. Construct points A and B in the plane such that AB equals 5. Then construct point C such that AC is perpendicular to BC and AC equals 4. On the line BC, choose points D and E such that B, E, D, and C are collinear in this order and BE equals ED equals DC. Then construct point F such that BF is perpendicular to CF and AE is parallel to BF. Find the length of segment AF. Given points A and B such that AB equals 5. Points D and E satisfy BE equals ED equals DC. Point F is defined such that AE is parallel to BF. Find the length of segment AF. "points": "A": [534, 409], "B": [54, 49], "C": [54, 409], "D": [54, 289], "E": [54, 169], "F": [198, 121], "segments": [["A", "B"], ["A", "C"], ["B", "C"], ["B", "E"], ["E", "D"], ["D", "C"], ["A", "D"], ["A", "E"], ["B", "F"], ["C", "F"], ["A", "F"]], "circles": [], "annotations": "right_angles": [["A", "C", "B"], ["B", "F", "C"]], "length_of_line": [[["A", "C"], "4"]], "measure_of_angle": [] "points“:"A":[520,395],"B":[70,60],"C":[70,395 ],"D":[70,290],"E":[70,175],"F":[220,140],“ seg ments":[["A","B"],["A","C"],["B","C"],["B","E"],["E ","D"],["D","C"],["A","D"],["A","E"],["B","F"],["C", "F"],["A","F"]],"circles":[],"annotations":" right_ angles":[["A","C","B"],["B","F","C"]]," length_of_l ine":[[["A","C"],"4"]],"measure_of_angle":[] From the diagram, points B, E, D, and C are collinear in the order B–E–D–C. Let the length of BC be 3, then BE = ED = DC = 1. For convenience, set up a coordinate system with B at the origin and BC along the positive x -axis. Then C is at (3, 0). Since AC is perpendicular to BC and AC = 4, point A lies on the vertical line through C, so A is at (3, 4). Consequently, E is at (1, 0) and D is at (2, 0). The line AE passes through A(3, 4) and E(1, 0), so its slope is (4 − 0) / (3 − 1) = 2, and a direction vector of AE can be taken as (1, 2). Because AE is parallel to BF, the slope of BF is also 2, hence the equation of BF is y = 2x. The condition BF is perpendicular to CF implies that point F lies on the circle with BC as diameter. The center of this circle is O(3/2, 0) and the radius is 3/2, so its equation is (x − 3/2)^2 + y^2 = (3/2)^2. Substituting y = 2x into the circle equation gives (x − 3/2)^2 + (2x)^2 = (3/2)^2, which simplifies to 5x^2 − 3x = 0. Excluding the solution x = 0 corresponding to point B, we obtain x = 3/5, and thus F is at (3/5, 6/5). Finally, the length of AF is computed as AF^2 = (3 − 3/5)^2 + (4− 6/5)^2 = (12/5)^2 + (14/5)^2 = 144/25 + 196/25 = 340/25 = 68/5, so AF = sqrt(68/5) = 2sqrt(85) / 5. Seed Construction Template-based Translation Numerical Q Plotting Code Debias Problem Model Output Diagram Diagram Render Figure 4 Exemplary data generation and model inference. The left panel illustrates the end-to-end synthesis process: from Symbolic Seed to Template-based Translation, followed by the Numerical Question, its corresponding Plotting Code, the Debiased Problem statement, and the finally rendered Diagram. The right panel showcases a real-world Inference Example, demonstrating the model’s ability to perform structured reasoning and code-based grounding during testing. we explicitly remove from the question all information that can be directly inferred from the diagram, such as relative positions, intersections, and marked equalities. Moreover, we rewrite the reasoning traces to reflect interactions between visual observations and textual premises, rather than purely symbolic deductions. As a result, solving the problem requires extracting geometric relations from the image instead of relying on redundant textual cues. 3.2 Plotting Code as Explicit Alignment Benefiting from our generation pipeline, each problem instance is associated not only with images, questions, and answers, but also with structured plotting code that explicitly describes the underlying geometric scene. This additional supervision enables us to move beyond answer-level learning and directly supervise geometric perception. Plotting code serves as a geometry-specific intermediate representation that can be deterministically rendered into diagrams and explicitly encodes geometric entities, constructions, and visual relations. From this perspective, understanding a geometry problem naturally corresponds to recovering its plotting code from the input image. Based on this observation, we train models to explicitly predict plotting code in addition to reasoning traces and final answers. Given an input diagram and question, the model is supervised to first reconstruct the geometric scene in the form of plotting code, and then perform reasoning and answer prediction based on the recovered structure. This design makes visual understanding an explicit learning process rather than an implicit latent process. Compared to answer-only or text-only supervision, plotting-code-based alignment enforces stronger coupling between visual perception and symbolic reasoning, which we empirically show to be critical for robust multimodal geometry reasoning. 4 Experiments In this section, we systematically evaluate the quality of the generated geometry problems and the effectiveness of the proposed alignment strategy. We first describe the implementation and experimental settings in Section 4.1. We then analyze the structural complexity and difficulty of our GeoCode in Section 4.2. Next, we evaluate how well models trained on our synthetic data transfer to public geometry benchmarks in Section 4.3. Finally, we conduct ablation studies to examine the roles of different pipeline components and plotting-code alignment in Sections 4.4 and 4.5. 7 Table 1 Structural statistics of proof-based and solution-based geometry problems. SegmentsAnnotationsCircles Proof15.031.940.14 Solution14.093.240.19 Table 2 Performance comparison of models on geometry benchmarks. Qwen3-VL stands for Qwen3-VL-32B-Thinking. BenchmarkGemini-2.5-ProGPT-5Qwen3-VL Geometry3K77.0479.0368.89 GeoQA92.0491.9186.60 OlympiadBench75.2275.5054.46 Test-mini40.6742.1631.72 4.1 Implementation Details Pipeline Implementation. We use GenesisGeo [34] for symbolic seed generation and structural selection. Instantiation, reasoning trace generation, semantic validation, textual debiasing, and plotting-code generation are all performed by GPT-OSS-120B [35]. Diagrams are rendered using OpenCV, followed by image-based quality filtering with Qwen3-VL-32B [36] to remove visually ambiguous samples. Training and Evaluation. All models are trained using LLaMA-Factory [37] with Qwen3-VL-7B-Instruct and Qwen2.5-VL-7B-Instruct as backbones, using LoRA-based SFT for 2 epochs (learning rate1× 10 −5 , warmup ratio 0.1). For reinforcement learning, we adopt standard GRPO optimization via the Verl framework [33,38], with learning rate5× 10 −6 , clip ratioε = 0.2, KL coefficientβ = 0.01, and 4 samples per prompt. All evaluations use identical prompts, greedy decoding (τ = 0), exact-match normalization, and images resized to 224× 224. 4.2 Quality and Difficulty of GeoCode Data. GeoCode contains a total of 18k geometry problems, including 13k numerical solution problems and 5k proof-based problems. For numerical problems, we randomly sample 2% of the data to form a held-out test-mini set, which is used for controlled difficulty analysis and comparison with standard benchmarks. All other experiments use disjoint training and test splits. Correctness. All generated samples are filtered by both semantic validation and coordinate geometric verifica- tion, ensuring consistency among symbolic relations, numerical constructions, and final answers. To further assess potential residual errors beyond automatic checks, We conduct manual inspection on a random 1% subset of the generated data, and observe no incorrect or inconsistent cases. Diversity. We analyze symbolic seeds to assess structural diversity. Overall, problems exhibit diverse combina- tions of geometric relations rather than single isolated constraints, and predicate usage follows a long-tailed distribution where frequent relations (e.g., perpendicularity, parallelism) coexist with less frequent but struc- turally important ones (e.g., cyclic and similarity constructions). This indicates that the dataset is not composed of repetitive templates but covers a wide range of geometric configurations. Complexity. We analyze problem complexity from both structural and difficulty perspectives. (1) Structure We evaluate not only symbolic seeds but also the final rendered diagrams, computing statistics such as the average number of segments and annotated relations per problem. The distributions show that most problems involve multiple entities and constraints, indicating higher structural richness compared to commonly used training data, as summarized in Table 1. (2) Difficulty To assess problem difficulty and prove complexity is meaningful, we compare model performance on the test-mini set with several standard geometry benchmarks under identical evaluation protocols. As shown in Table 2, test-mini exhibits higher difficulty, reflecting the 8 ModelSettingGeometry3KMathVerseMathVistaGeoQAOlympiadBenchTest-mini Qwen3-VL-7B-Instruct Baseline58.5763.3383.1983.1645.8217.91 Ours60.0765.1084.4584.2157.3426.49 ∆+1.50+1.77+1.26+1.05+11.52+8.58 Qwen2.5-VL-7B-Instruct Baseline33.9037.6460.9262.605.764.48 Ours40.0946.0857.5666.446.6313.06 ∆+6.19+8.44-3.36+3.84+0.87+8.58 Table 3 Benchmark performance (%) of Instruct models before and after training on our dataset.∆denotes absolute improvement of Ours over the original baseline. ModelBase+SFT+GRPO Qwen3-VL48 (17.91)71 (26.49)101 (37.68) Qwen2.5-VL12 (4.48)35 (13.06)55 (20.52) Table 4 Accuracy on the held-out Test-mini set. Models are evaluated under three training stages: original pretrained backbones (Base), SFT on our synthetic dataset, and reinforcement learning with standard GRPO built upon the SFT models. non-trivial reasoning complexity of the generated problems. Figure 4 qualitatively demonstrates our dataset’s complexity and consistency, showcasing the full transition from seed to debiased problem, plotting code, and rendered diagram. More statistics can be found in Appendix F. 4.3 Effectiveness on Test-mini and Public Benchmarks Evaluation on Test-mini. We first evaluate models trained on GeoCode on Test-mini, a held-out subset constructed from unseen symbolic seeds and instantiations, which exhibits higher structural complexity and denser geometric constraints than standard benchmarks. To more directly assess the effectiveness of the generated data, we adopt a two-stage training scheme with SFT followed by GRPO. Notably, during the GRPO stage, we apply rewards only on answer correctness and output format, without supervising intermediate reasoning traces or plotting code, so that improvements can be attributed to data quality rather than additional structured supervision. As shown in Table 4, both backbones benefit substantially from SFT and further improve with GRPO. For Qwen3-VL-Instruct, accuracy increases from 17.9% to 26.5% after SFT and further to 37.7% after GRPO, while Qwen2.5-VL-Instruct improves from 4.5% to 13.1% and then to 20.5%, respectively. These consistent gains indicate that GeoCode provides strong and stable learning signals even when reinforcement learning is driven solely by final-answer supervision, demonstrating the intrinsic effectiveness of the generated problems. Transfer to Public Geometry Benchmarks. To evaluate out-of-distribution generalization, we further assess models on multiple public benchmarks, including Geometry3K [13], MathVerse [18], MathVista [17], GeoQA [14], and OlympiadBench [16]. For general vision–math benchmarks, we report results only on plane-geometry subsets. As shown in Table 3, models trained on GeoCode outperform their baselines on most benchmarks. In particular, Qwen3-VL-Instruct achieves a large improvement on OlympiadBench (+11.5), one of the most challenging geometry benchmarks, suggesting enhanced robustness on complex multi-step reasoning. Qwen2.5-VL-Instruct also shows notable gains on Geometry3K (+6.2), MathVerse (+8.4), and GeoQA (+3.8). Overall, these results indicate that models trained on GeoCode learn transferable geometric representations and reasoning patterns, rather than overfitting to the synthetic generation distribution. 4.4 Ablation Study on Pipeline Components Filtering at Different Stages of the Pipeline. We track candidate counts at each stage to analyze the contribution of different modules. From 264,705 randomly sampled symbolic structures, only 35,297 remain after seed selection, and 18,176 survive all subsequent stages (Table 5). This reduction mainly reflects the removal of 9 StageRejected Samples Semantic validation10,510 Geometric verification4,171 Plotting execution2,017 Image quality filter423 Total rejected17,121 Final retained18,176 Table 5 Detailed rejection statistics during the multi-stage validation pipeline. Alignment SettingTest-mini (%)Geometry3K (%) A. None17.9158.57 B. Caption19.7858.74 C. Caption + Debias20.5259.07 D. Code22.0159.57 E. Code + Debias26.4960.07 Table 6 Comparative analysis of alignment supervision strategies. structurally trivial seeds that are unlikely to yield meaningful geometric relations or multi-step reasoning, rather than invalid constructions. Seed selection is computationally lightweight and effectively prunes low-value structures early, without becoming a pipeline bottleneck. Verification and Visualization as Quality Gates. On the remaining candidates, nearly half are further filtered by subsequent stages due to different failure types. Specifically, 10,510 are rejected by semantic validation for inconsistencies among statements, reasoning traces, and answers; 4,171 fail coordinate geometric checks; 2,017 are discarded due to invalid plotting code execution; and 423 are removed by visual quality filtering. As a result, only 18,176 out of 35,297 (51.5%) pass all stages. These failures correspond to distinct error modes spanning linguistic coherence, geometric validity, construction executability, and visual clarity, indicating that the pipeline functions as a sequence of complementary quality gates rather than redundant checks. 4.5 Plotting Code Enables Stronger Visual Alignment To compare different alignment supervision forms, we consider two prediction targets during SFT, plotting code and natural-language captions of the diagram. Captions are generated by Qwen3-VL-32B conditioned on both the rendered diagram and its plotting code. All other inputs are kept identical, and models are trained to regress either code or captions. Results are reported in Table 6. Figure 4 further shows that predicting plotting code before reasoning enables explicit reconstruction of geometric scenes, grounding visual perception in verifiable geometric relations. Effectiveness of Code Alignment. Alignment supervision improves performance over the no-alignment baseline, with plotting code yielding the most substantial gains on both Test-mini and Geometry3K, while caption-based supervision brings only marginal improvements. Although captions and plotting code describe the same geometry, natural language is weakly structured and admits diverse surface realizations, whereas plotting code explicitly specifies constructions and spatial relations, forcing models to recover underlying geometric structure and thus providing a stronger alignment signal between vision and geometry. We further observe that textual debiasing brings additional gains mainly when combined with code-based supervision, suggesting that debiasing strengthens visual grounding once explicit structural prediction is required. Structural Recovery and Solving Performance. To verify that the gains from code alignment arise from improved geometric perception rather than only better answer generation, we directly evaluate the structural quality of predicted plotting code on Test-mini, where ground-truth structure is available. We measure segment-level F1 10 0 25%2550%5075%75100% Segment-level F1 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 Accuracy 13.4% (9/67) 28.4% (19/67) 50.7% (34/67) 58.2% (39/67) Figure 5 Solving accuracy and segment-level structural recovery quality on Test-mini. Samples are grouped into four equal-sized bins according to segment-level F1 between predicted and ground-truth plotting code. between predicted and ground-truth segments and group samples into equal-sized bins. As shown in Fig. 5, solving accuracy increases with higher segment-level F1, indicating that improved recovery of geometric configurations is closely associated with better reasoning performance. See Appendix B for further details, experiments and analysis. 5 Conclusion We present a pipeline for synthesizing multimodal geometry problems from scratch, with multi-stage validation to ensure consistency among symbolic structures, text, reasoning traces, and diagrams. By decoupling generation into symbolic seed construction, grounded instantiation, and code-based visualization, the pipeline enables scalable synthesis of structurally complex geometry problems. Based on this pipeline, we construct GeoCode, a high-quality dataset pairing each problem with diagrams, solutions, and plotting code, providing explicit supervision for both perception and reasoning. Leveraging the plotting code, we further explore code prediction as an alignment strategy, which encourages models to recover underlying geometric constructions from diagrams and yields more robust visual grounding than text-based supervision, leading to improve performance across multiple geometry benchmarks. 11 Impact Statement This work aims to advance multimodal machine learning by improving visual–symbolic alignment and reasoning in geometry, a core domain for studying structured multimodal understanding. Potential positive impacts include supporting research on multimodal reasoning, enabling better educational tools for geometry learning, and facilitating future studies on interpretable visual–symbolic models. All data used in this work are synthetically generated through automated symbolic and geometric procedures, and do not involve personal data, sensitive content, or real-world imagery, thereby posing no privacy or data protection concerns. As with many advances in reasoning-capable language and vision–language models, there is a general risk that improved problem-solving abilities could be misused for academic dishonesty or automated answer generation. However, this risk is not specific to our method and is shared by most progress in large-scale reasoning models. We believe that the primary and intended use of our work is to support research and education, and we do not foresee significant negative societal consequences specific to this contribution. 12 References [1]Liangyu Xu, Yingxiu Zhao, Jingyun Wang, Yingyao Wang, Bu Pi, Chen Wang, Mingliang Zhang, Jihao Gu, Xiang Li, Xiaoyong Zhu, et al. Geosense: Evaluating identification and application of geometric principles in multimodal reasoning.arXivpreprintarXiv:2504.12597, 2025. [2]Bowen Ping, Minnan Luo, Zhuohang Dang, Chenxi Wang, and Chengyou Jia. Autogps: Automated geometry problem solving via multimodal formalization and deductive reasoning.arXivpreprintarXiv:2505.23381, 2025. [3]Shichao Weng, Zhiqiang Wang, Yuhua Zhou, Rui Lu, Ting Liu, Zhiyang Teng, Xiaozhang Liu, and Hanmeng Liu. Geosketch: A neural-symbolic approach to geometric multimodal reasoning with auxiliary line construction and affine transformation.arXivpreprintarXiv:2509.22460, 2025. [4]Seunghyuk Cho, Zhenyue Qin, Yang Liu, Youngbin Choi, Seungbeom Lee, and Dongwoo Kim. Plane geometry problem solving with multi-modal reasoning: A survey.arXivpreprintarXiv:2505.14340, 2025. [5]Junnan Li, Dongxu Li, Caiming Xiong, and Steven Hoi. Blip: Bootstrapping language-image pre-training for unified vision-language understanding and generation. InInternationalconferenceonmachinelearning, pages 12888–12900. PMLR, 2022. [6] Haotian Liu, Chunyuan Li, Qingyang Wu, and Yong Jae Lee. Visual instruction tuning.Advancesinneuralinformation processingsystems, 36:34892–34916, 2023. [7]Junnan Li, Dongxu Li, Silvio Savarese, and Steven Hoi. Blip-2: Bootstrapping language-image pre-training with frozen image encoders and large language models. InInternationalconferenceonmachinelearning, pages 19730–19742. PMLR, 2023. [8] OpenAI. Gpt-4v(ision) system card.https://openai.com/index/gpt-4v-system-card/, 2023. Official system card describing GPT-4V, a multimodal vision–language model. [9] Jinze Bai, Shuai Bai, Shusheng Yang, Shijie Wang, Sinan Tan, Peng Wang, Junyang Lin, Chang Zhou, and Jingren Zhou. Qwen-vl: A frontier large vision-language model with versatile abilities.arXivpreprintarXiv:2308.12966, 1(2):3, 2023. [10] Peng Wang, Shuai Bai, Sinan Tan, Shijie Wang, Zhihao Fan, Jinze Bai, Keqin Chen, Xuejing Liu, Jialin Wang, Wenbin Ge, et al. Qwen2-vl: Enhancing vision-language model’s perception of the world at any resolution.arXivpreprint arXiv:2409.12191, 2024. [11]Zhe Chen, Jiannan Wu, Wenhai Wang, Weijie Su, Guo Chen, Sen Xing, Muyan Zhong, Qinglong Zhang, Xizhou Zhu, Lewei Lu, et al. Internvl: Scaling up vision foundation models and aligning for generic visual-linguistic tasks. In ProceedingsoftheIEEE/CVFconferenceoncomputervisionandpatternrecognition, pages 24185–24198, 2024. [12]Tianyi Bai, Hao Liang, Binwang Wan, Yanran Xu, Xi Li, Shiyu Li, Ling Yang, Bozhou Li, Yifan Wang, Bin Cui, et al. A survey of multimodal large language model from a data-centric perspective.arXivpreprintarXiv:2405.16640, 2024. [13]Pan Lu, Ran Gong, Shibiao Jiang, Liang Qiu, Siyuan Huang, Xiaodan Liang, and Song-Chun Zhu. Inter-gps: Inter- pretable geometry problem solving with formal language and symbolic reasoning.arXivpreprintarXiv:2105.04165, 2021. [14] Jiaqi Chen, Jianheng Tang, Jinghui Qin, Xiaodan Liang, Lingbo Liu, Eric Xing, and Liang Lin. Geoqa: A geomet- ric question answering benchmark towards multimodal numerical reasoning. InFindingsoftheAssociationfor ComputationalLinguistics:ACL-IJCNLP2021, pages 513–523, 2021. [15]Jie Cao and Jing Xiao. An augmented benchmark dataset for geometric question answering through dual parallel text encoding. InProceedingsofthe29thinternationalconferenceoncomputationallinguistics, pages 1511–1520, 2022. [16] Chaoqun He, Renjie Luo, Yuzhuo Bai, Shengding Hu, Zhen Thai, Junhao Shen, Jinyi Hu, Xu Han, Yujie Huang, Yuxiang Zhang, et al. Olympiadbench: A challenging benchmark for promoting agi with olympiad-level bilingual multimodal scientific problems. InProceedingsofthe62ndAnnualMeetingoftheAssociationforComputational Linguistics(Volume1:LongPapers), pages 3828–3850, 2024. [17] Pan Lu, Hritik Bansal, Tony Xia, Jiacheng Liu, Chunyuan Li, Hannaneh Hajishirzi, Hao Cheng, Kai-Wei Chang, Michel Galley, and Jianfeng Gao. Mathvista: Evaluating mathematical reasoning of foundation models in visual contexts. arXivpreprintarXiv:2310.02255, 2023. 13 [18]Renrui Zhang, Dongzhi Jiang, Yichi Zhang, Haokun Lin, Ziyu Guo, Pengshuo Qiu, Aojun Zhou, Pan Lu, Kai-Wei Chang, Yu Qiao, et al. Mathverse: Does your multi-modal llm truly see the diagrams in visual math problems? In EuropeanConferenceonComputerVision, pages 169–186. Springer, 2024. [19]Trieu H Trinh, Yuhuai Wu, Quoc V Le, He He, and Thang Luong. Solving olympiad geometry without human demonstrations.Nature, 625(7995):476–482, 2024. [20] Yuri Chervonyi, Trieu H Trinh, Miroslav Olšák, Xiaomeng Yang, Hoang H Nguyen, Marcelo Menegali, Junehyuk Jung, Junsu Kim, Vikas Verma, Quoc V Le, et al. Gold-medalist performance in solving olympiad geometry with alphageometry2.JournalofMachineLearningResearch, 26(241):1–39, 2025. [21]Zhihao Li, Yao Du, Yang Liu, Yan Zhang, Yufang Liu, Mengdi Zhang, and Xunliang Cai. Eagle: Elevating geometric reasoning through llm-empowered visual instruction tuning.arXivpreprintarXiv:2408.11397, 2024. [22]Renrui Zhang, Xinyu Wei, Dongzhi Jiang, Ziyu Guo, Shicheng Li, Yichi Zhang, Chengzhuo Tong, Jiaming Liu, Aojun Zhou, Bin Wei, et al. Mavis: Mathematical visual instruction tuning with an automatic data engine.arXivpreprint arXiv:2407.08739, 2024. [23]Jiahui Gao, Renjie Pi, Jipeng Zhang, Jiacheng Ye, Wanjun Zhong, Yufei Wang, Lanqing Hong, Jianhua Han, Hang Xu, Zhenguo Li, et al. G-llava: Solving geometric problem with multi-modal large language model.arXivpreprint arXiv:2312.11370, 2023. [24]Linger Deng, Yuliang Liu, Bohan Li, Dongliang Luo, Liang Wu, Chengquan Zhang, Pengyuan Lyu, Ziyang Zhang, Gang Zhang, Errui Ding, et al. R-cot: Reverse chain-of-thought problem generation for geometric reasoning in large multimodal models.arXive-prints, pages arXiv–2410, 2024. [25]Ke Wang, Junting Pan, Linda Wei, Aojun Zhou, Weikang Shi, Zimu Lu, Han Xiao, Yunqiao Yang, Houxing Ren, Mingjie Zhan, et al. Mathcoder-vl: Bridging vision and code for enhanced multimodal mathematical reasoning. arXivpreprintarXiv:2505.10557, 2025. [26]Yicheng Pan, Zhenrong Zhang, Pengfei Hu, Jiefeng Ma, Jun Du, Jianshu Zhang, Quan Liu, Jianqing Gao, and Feng Ma. Enhancing the geometric problem-solving ability of multimodal llms via symbolic-neural integration. InProceedings ofthe33rdACMInternationalConferenceonMultimedia, pages 5394–5403, 2025. [27]Daocheng Fu, Zijun Chen, Renqiu Xia, Qi Liu, Yuan Feng, Hongbin Zhou, Renrui Zhang, Shiyang Feng, Peng Gao, Junchi Yan, et al. Trustgeogen: Scalable and formal-verified data engine for trustworthy multi-modal geometric problem solving.arXivpreprintarXiv:2504.15780, 2025. [28]Xiang Yue, Yuansheng Ni, Kai Zhang, Tianyu Zheng, Ruoqi Liu, Ge Zhang, Samuel Stevens, Dongfu Jiang, Weiming Ren, Yuxuan Sun, et al. Mmmu: A massive multi-discipline multimodal understanding and reasoning benchmark for expert agi. InProceedingsoftheIEEE/CVFConferenceonComputerVisionandPatternRecognition, pages 9556–9567, 2024. [29]Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 technical report.arXivpreprintarXiv:2303.08774, 2023. [30]Tianyi Bai, Zengjie Hu, Fupeng Sun, Jiantao Qiu, Yizhen Jiang, Guangxin He, Bohan Zeng, Conghui He, Binhang Yuan, and Wentao Zhang. Multi-step visual reasoning with visual tokens scaling and verification.arXivpreprint arXiv:2506.07235, 2025. [31]Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of- thought prompting elicits reasoning in large language models.Advancesinneuralinformationprocessingsystems, 35:24824–24837, 2022. [32]John Schulman, Filip Wolski, Prafulla Dhariwal, Alec Radford, and Oleg Klimov. Proximal policy optimization algorithms.arXivpreprintarXiv:1707.06347, 2017. [33]Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, YK Li, Yang Wu, et al. Deepseekmath: Pushing the limits of mathematical reasoning in open language models.arXiv preprintarXiv:2402.03300, 2024. [34]Minfeng Zhu, Zi Wang, Sizhe Ji, Zhengtong Du, Junming Ke, Xiao Deng, Zanlang Yin, Xiuqi Huang, Heyu Wang, and Wei Chen. Genesisgeo: Technical report.arXivpreprintarXiv:2509.21896, 2025. 14 [35]OpenAI. Introducing gpt-oss.https://openai.com/index/introducing-gpt-oss/, August 2025. Accessed: 2026-01-25. [36]Shuai Bai, Yuxuan Cai, Ruizhe Chen, Keqin Chen, Xionghui Chen, Zesen Cheng, Lianghao Deng, Wei Ding, Chang Gao, Chunjiang Ge, Wenbin Ge, Zhifang Guo, Qidong Huang, Jie Huang, Fei Huang, Binyuan Hui, Shutong Jiang, Zhaohai Li, Mingsheng Li, Mei Li, Kaixin Li, Zicheng Lin, Junyang Lin, Xuejing Liu, Jiawei Liu, Chenglong Liu, Yang Liu, Dayiheng Liu, Shixuan Liu, Dunjie Lu, Ruilin Luo, Chenxu Lv, Rui Men, Lingchen Meng, Xuancheng Ren, Xingzhang Ren, Sibo Song, Yuchong Sun, Jun Tang, Jianhong Tu, Jianqiang Wan, Peng Wang, Pengfei Wang, Qiuyue Wang, Yuxuan Wang, Tianbao Xie, Yiheng Xu, Haiyang Xu, Jin Xu, Zhibo Yang, Mingkun Yang, Jianxin Yang, An Yang, Bowen Yu, Fei Zhang, Hang Zhang, Xi Zhang, Bo Zheng, Humen Zhong, Jingren Zhou, Fan Zhou, Jing Zhou, Yuanzhi Zhu, and Ke Zhu. Qwen3-vl technical report.arXivpreprintarXiv:2511.21631, 2025. Technical Report on the most advanced vision-language model in the Qwen series, with extended context support and enhanced multimodal reasoning. [37] Yaowei Zheng, Richong Zhang, Junhao Zhang, Yanhan Ye, Zheyan Luo, Zhangchi Feng, and Yongqiang Ma. Llamafac- tory: Unified efficient fine-tuning of 100+ language models.arXivpreprintarXiv:2403.13372, 2024. Accessed: 2026-01-25. [38]Guangming Sheng, Chi Zhang, Zilingfeng Ye, Xibin Wu, Wang Zhang, Ru Zhang, Yanghua Peng, Haibin Lin, and Chuan Wu. Hybridflow: A flexible and efficient rlhf framework. InProceedingsoftheTwentiethEuropeanConferenceon ComputerSystems, pages 1279–1297, 2025. [39] P. Langley. Crafting papers on machine learning. In Pat Langley, editor,Proceedingsofthe17thInternational ConferenceonMachineLearning(ICML2000), pages 1207–1216, Stanford, CA, 2000. Morgan Kaufmann. [40]Xiaokai Zhang, Na Zhu, Yiming He, Jia Zou, Qike Huang, Xiaoxiao Jin, Yanjun Guo, Chenyang Mao, Yang Li, Zhe Zhu, et al. Formalgeo: An extensible formalized framework for olympiad geometric problem solving.arXivpreprint arXiv:2310.18021, 2023. [41]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. Qwen2.5-vl technical report.arXivpreprintarXiv:2502.13923, 2025. Technical Report on a flagship vision-language model series (Qwen2.5-VL) with enhanced visual recognition, structured extraction, and video understanding. [42]Vladmir Sicca, Tianxiang Xia, Mathïs Fédérico, Philip John Gorinski, Simon Frieder, and Shangling Jui. Newclid: A user-friendly replacement for alphageometry with agentic support.arXivpreprint, 2024. 15 A Discussion In this section, we compare our approach with existing methods and discuss future directions. Our work focuses on synthesizing multimodal geometry data and enabling effective visual alignment. We first examine related data synthesis methods, then highlight our core innovations, and finally outline promising future directions. Comparison with Existing Data Synthesis Methods. Early data synthesis approaches for geometry reasoning primarily focused on augmenting existing datasets rather than generating new visual content. G-LLaVA [23] represents one of the earliest data synthesis methods in this domain, but it does not generate new images; instead, it augments datasets through semantic modifications and explores text-based visual geometric alignment using predicate-based methods. Subsequent works have advanced toward generating novel images. R-CoT [24] employs a sampling-based approach to select geometric configurations and synthesizes geometry data using large language models. GeoGen [26] leverages the symbolic engine FormalGeo [40] to search in symbolic space and translates results using LLMs. TrustGeoGen [27] represents a particularly powerful approach that exclusively searches in symbolic space using the AlphaGeometry engine to synthesize data. MathCoder-VL [25] introduces an interesting variation by adjusting temperature parameters to generate novel figures through code, synthesizing instruction pairs using LLMs, and validating correctness through A/B testing. We acknowledge the valuable insights these works have provided for our research. Compared to these approaches, our method introduces several core innovations.First, we decompose the synthesis process into three distinct stages, factorizing geometry into basic structure, instance information, and visualization code. This decomposition is not only more intuitive but has also proven more effective in practice, enabling the generation of more diverse structures and leveraging LLM priors to produce interesting problems. From this perspective, our approach differs fundamentally from the aforementioned works.Second, code-based visualization provides complete geometric information, allowing us to thoroughly explore the role of visual modalities. Through debiasing and explicit alignment methods, we promote visual understanding, representing a deeper investigation beyond synthesis. Unlike G-LLaVA [23], MAVIS [22], and EAGLE [21], which employ different alignment strategies, our approach uses plotting code for alignment, which we empirically demonstrate to be more effective.Third, we acknowledge that LLM hallucinations pose challenges for synthesizing mathematical problems, necessitating multiple validation mechanisms. Therefore, we implement multi-level verification through semantic, numerical, and visual checks to ensure the correctness of multimodal problems. In particular, our code-based verification represents a significant step forward in synthesizing mathematical geometry problems. Future Directions. Looking ahead, we believe that data synthesis methods will inspire more downstream tasks, particularly in areas such as Thinking With Images, enabling more effective supervision or reinforcement learning algorithm development. However, data synthesis represents only the first step. We also hope that code-based alignment approaches can find broader applications, where explicit structural grounding can bridge the gap between visual perception and symbolic reasoning. B A Closer Look at Plotting Code as Alignment Signal As demonstrated in Section 4.5, code-based alignment supervision yields substantial improvements over caption-based or no-alignment baselines. In this appendix, we provide a closer diagnostic analysis to clarify whatthe model learns from plotting-code supervision. In particular, we aim to distinguish two plausible explanations: (i) the model mainly benefits from learning a rigid output format (i.e., producing well-formed code), or (i) the model truly improves its ability to reconstruct geometric structure from the diagram, which subsequently supports correct reasoning. Segment-Level Structural F1: Definition and Motivation. To directly probe structural understanding beyond final answers, we introduce segment-level F1 as a geometry-aware evaluation metric on Test-mini, where ground-truth plotting code is available. The key idea is simple: if a model genuinely “sees” the diagram structure, it should be able to recover the correct set of segments (edges) that define the core relational 16 ParsableNon-parsable Parsing status 0 5 10 15 20 25 30 35 40 45 Solving accuracy (%) 37.9% 36.7% (a) Solving accuracy under parsable vs. non-parsable plotting code. Correct annotation Incorrect annotation Annotation quality 0 10 20 30 40 50 60 Solving accuracy (%) 51.2% 15.2% (b) Solving accuracy under correct vs. incorrect structural annotation. Figure 6 Diagnostic analysis of code-based alignment quality on Test-mini. Left: Successful execution (parsing) of plotting code shows little correlation with final solving accuracy. Right: Structural correctness of predicted annotation is strongly correlated with solving performance, indicating that faithful geometric reconstruction is the key factor affecting downstream reasoning. skeleton of the construction. We focus on segments because they provide a stable and nearly canonical representation of structure. A segment is uniquely identified by an unordered pair of endpoints. Concretely, for each instance we extract the segment set from predicted plotting code and ground-truth plotting code, denoted asS pred andS gt , where each segment is represented as an unordered endpoint pair. We compute precision, recall, and F1 by: P = |S pred ∩ S gt | |S pred | , R = |S pred ∩ S gt | |S gt | ,(1) F1 = 2PR P + R .(2) We then rank all Test-mini samples by their segment-level F1 and split them into four equal-sized groups (quartiles). The main-text result (Fig. 5) shows a clear monotonic trend: higher segment-level F1 is consistently associated with higher solving accuracy. Importantly, this metric isstructuralrather than outcome-driven: it evaluates whether the predicted code recovers the correct geometric relations encoded by the diagram, independent of how the model verbalizes its reasoning or formats its final answer. Therefore, the positive correlation provides direct evidence that the gains from plotting-code supervision are tied to improved structural reconstruction ability. Parsing Is Not the Bottleneck. A natural concern is that plotting code might mainly help because it enforces a strict output template, and the observed gains could simply reflect “format learning” rather than better geometry understanding. To test this hypothesis, we examine the relationship between parsing success and solving accuracy (Fig. 6a). On Test-mini, the model achieves a high parsing success rate:219cases are parsable, corresponding to81.7%successful parsing. This already indicates that the surface format of plotting code is learned relatively quickly. However, parsing success itself shows little explanatory power for downstream problem solving. Among the parsable cases,83/219are solved correctly (37.9%). Among the49non-parsable cases,18/49are solved correctly (36.7%). The accuracy difference is negligible, suggesting that syntactic well-formedness or executability is not the key factor determining whether the model can solve the problem. In other words, the model can often answer correctly even when its code cannot be parsed, and conversely, it can still fail even when it produces well-formed code. This observation strongly argues against the “format-only” 17 explanation: the improvement from code supervision cannot be reduced to merely learning how to emit a JSON-like structure. Why Annotations Matter. If formatting is not the driver, what aspect of plotting code is most predictive of reasoning success? We further analyze a structure-critical component: geometric annotations (e.g., right angles, lengths, and other marked constraints), which are known to be decisive in classical geometry problem solving because they specify the nontrivial constraints that reasoning must operate on. We focus on the189 Test-mini instances that contain explicit annotations and manually assess whether the predicted annotation is structurally correct (fully correct vs. partially/fully incorrect). The results (Fig. 6b) reveal a strong dependence on annotation fidelity. When the predicted annotation is fully correct, solving accuracy reaches43/84 = 51.2%. When the annotation is partially or fully incorrect, accuracy drops sharply to16/105 = 15.2%. This gap is substantial and qualitatively different from the parsing analysis above. It indicates that recovering the rightconstraints—not merely producing a valid container—plays a central role in enabling correct reasoning. Conceptually, this is exactly what we expect from geometry: annotations act as “hard facts” that anchor the deductive process. A small structural mistake (e.g., missing a right angle or mis-assigning an equality) can invalidate the entire reasoning chain, even if all other parts of the diagram are correctly recognized. Therefore, annotation correctness provides a more faithful diagnostic for geometric understanding than format validity. Summary. Taken together, these analyses paint a consistent picture of how plotting code functions as an alignment signal. Segment-level F1 demonstrates that better structural recovery of segments is tightly associated with higher solving accuracy, supporting the claim that code supervision strengthens geometric perception and structure reconstruction. The parsing analysis further rules out a superficial explanation: models can quickly learn the plotting-code format (high parsing success), yet format validity alone has little correlation with whether problems are solved correctly. In contrast, annotation correctness shows a strong and practically meaningful relationship with solving performance, highlighting that what truly matters is faithful recovery of geometric constraints and relations. Overall, these results support our central conclusion: plotting- code supervision improves multimodal geometry reasoning not by enforcing a rigid output template, but by explicitly training models to reconstruct diagram structure—especially constraint-bearing relations—thereby providing a reliable internal representation that downstream reasoning can build upon. C Training and Evaluation Details This section provides detailed specifications of our training and evaluation procedures, including supervised fine-tuning (SFT) and reinforcement learning with GRPO. C.1 Supervised Fine-Tuning We perform SFT using cross-entropy loss on our synthetic geometry dataset. The training configuration is as follows: Model Configuration. We use Qwen2.5-VL-7B-Instruct and Qwen3-VL-7B-Instruct as base models, both following identical training configurations. The vision tower is frozen during training, while the multi-modal projector and language model are fine-tuned. We employ LoRA with rank 128, applied to all trainable parameters. The maximum image resolution is set to 512× 512 pixels (262,144 total pixels). Training Hyperparameters. The model is trained for 2 epochs with a learning rate of1.0× 10 −5 using cosine learning rate scheduling. We use a warmup ratio of 0.1, batch size of 4 per device with gradient accumulation over 8 steps (effective batch size of 32), and bfloat16 precision. The maximum sequence length is set to 8192 tokens. We train on 18k samples from our synthetic dataset. Loss Function. During SFT, we minimize the standard cross-entropy loss: L SFT =− T X t=1 logP (y t | y <t ,x,I), 18 wherexis the input text prompt,Iis the input image,y t is the token at positiont, andTis the total sequence length. The model is supervised to predict plotting code, reasoning traces, and final answers. C.2 Reinforcement Learning with GRPO After SFT, we further optimize the model using Group Relative Policy Optimization (GRPO) [33], a variant of PPO that groups multiple responses for more stable policy updates. GRPO Objective. The GRPO objective function is defined as: L GRPO =E (x,I)∼D " 1 G G X g=1 n g X i=1 (r(x,I,y g,i )− ̄r g ) logπ θ (y g,i | x,I)− βKL(π θ ∥π ref ) # , whereGis the number of groups,n g is the number of responses in groupg,r(x,I,y g,i )is the reward for responsey g,i , ̄r g = 1 n g P n g i=1 r(x,I,y g,i )is the group mean reward,π θ is the current policy,π ref is the reference policy (the SFT model), and β = 0.01 is the KL penalty coefficient. Reward Function. We employ a composite reward function that combines format correctness and answer accuracy: r(x,I,y) = r format (y) + r answer (x,I,y), wherer format (y)∈0, 1is a binary reward for correct output format, andr answer (x,I,y)∈0, 1is a binary reward for answer correctness. The format rewardr format (y)requires the model output to follow the structure with three explicitly delimited blocks: <code> C </code> <think> R </think> <answer> A </answer>, whereCis the plotting code,Ris the reasoning trace (placed inside<think> </think>), andAis the final answer (placed inside<answer> </answer>). The format reward is 1 if the output contains all three required components in the correct order with correct opening and closing tags, and 0 otherwise. The answer rewardr answer (x,I,y)is 1 if the extracted answerAmatches the ground truth answer (with numerical tolerance for floating-point comparisons), and 0 otherwise. Training Configuration. We train for 1 epoch with a learning rate of5.0× 10 −6 . The training batch size is 256, with PPO mini-batch size of 128 and micro-batch size of 8 per GPU. We samplen = 4responses per prompt for reward estimation. The KL loss uses the low-variance KL estimator with coefficientβ = 0.01, and the clip ratio is set toε = 0.2. We use FSDP (Fully Sharded Data Parallel) for distributed training across 4 H200 GPUs, with gradient checkpointing enabled to reduce memory usage. Implementation Details. The rollout and reference models use tensor model parallelism with size 2. The rollout engine uses vLLM with GPU memory utilization set to 0.6. We disable the multi-modal preprocessor cache and use eager execution mode. The maximum prompt and response lengths are both set to 2048 tokens. C.3 Evaluation Protocol Test Set Construction. For non-geometry-specific datasets, we follow the original dataset annotations and select subsets that involve plane geometry problems. Table 7 summarizes the sizes of these geometry-focused minisets extracted from each benchmark. 19 DatasetTest Set Size Geometry3K601 GeoQA754 OlympiadBench347 MathVerse510 MathVista238 Table 7 Test set sizes for geometry-focused subsets extracted from each benchmark. 020406080100120140 Step 0.13 0.14 0.15 0.16 0.17 0.18 Critic score 020406080100120140 Step 0.150 0.175 0.200 0.225 0.250 0.275 0.300 Critic score Figure 7 GRPO reward curves for different backbones. Qwen2.5-VL [41] (left) exhibits slower reward growth with larger fluctuations, while Qwen3-VL [36] (right) shows a more stable and monotonic improvement, indicating stronger geometric reasoning ability and better alignment with our hard, structurally complex data. Evaluation Details. To ensure fair and consistent evaluation across all models, we adopt a standardized evaluation protocol. We set the temperature parameterτ = 0for all evaluations, enabling deterministic greedy decoding. All models use the same system prompt: You are a mathematical reasoning assistant. Your task is to solve the problem and give the correct answer. For answer extraction and matching, we parse answers from either<answer>or<box>tags in the model output. We then process the extracted answers through LaTeX parsing and symbolic evaluation using SymPy to compute numerical values. An answer is considered correct if the computed value matches the ground truth answer within a tolerance of10 −6 . This numerical matching approach ensures robust evaluation across different answer formats and representations. To maintain fairness, all models are evaluated using identical evaluation procedures, including the same answer extraction logic, parsing methods, and matching criteria. We evaluate only problems that require solution generation (i.e., solution-type problems), excluding other problem types from the evaluation. D Effect of Backbone Models By constructing hard and structurally complex geometry instances that require multi-step reasoning and sophisticated spatial understanding, our method provides a natural testbed for evaluating how different vision-language backbones respond to reinforcement learning optimization. We compare Qwen2.5-VL [41] and Qwen3-VL [36] under identical GRPO training configurations, examining both their final performance on Test-mini (Table 4) and their training dynamics through reward curves (Figure 7). The results reveal a clear distinction between the two backbones. Qwen3-VL [36], which has been extensively pre-trained on STEM and geometry-related corpora, demonstrates superior geometric reasoning capabilities: during GRPO training, its average reward exhibits steady, monotonic growth and converges to a high, stable plateau (Figure 7, right). This behavior suggests that Qwen3-VL can effectively leverage the structural complexity and difficulty of our generated data to drive consistent policy improvement. In contrast, while Qwen2.5-VL [41] also benefits from GRPO and achieves notable gains (from 13.1% to 20.5% on Test-mini), its 20 ModelBaselineOODOurs∆ (Ours–OOD) Qwen3-VL-Instruct83.1684.2189.66+5.45 Qwen2.5-VL-Instruct62.6066.4468.83+2.39 Table 8 Extending our pipeline with text-seeded synthetic data on GeoQA. “Baseline” denotes the original pretrained backbones, “OOD” denotes training only on our synthetic dataset, and “Ours” further augments training with data synthesized by feeding real textual problem statements into our instantiation and visualization stages. The extended pipeline yields consistent gains for both backbones, indicating that our method can effectively adapt to existing geometry corpora and narrow the domain gap. reward curve displays slower growth and significantly larger variance throughout training (Figure 7, left), indicating less stable optimization and lower sample efficiency. This comparison yields two important insights. First, backbone selection is critical for vertical domains like geometry, where specialized pre-training on domain-relevant data substantially facilitates downstream reinforcement learning. Second, the high difficulty and structural richness of our automatically generated data serve as an effective probe that can distinguish between strong backbones, validating both the quality of our data generation pipeline and its utility for benchmarking geometric reasoning capabilities. E Extensibility of Our Pipeline Our generation pipeline is divided into three stages: symbolic seed generation, instance instantiation, and visualization. The first stage lays down the underlying geometric structure, while the latter two stages materialize concrete problem instances and diagrams. This modular design naturally raises the question of whether the pipeline can be extended toingestexisting textual problems and synthesize new data that reduces the domain gap between our synthetic distribution and established benchmarks. To explore this direction, we examine common geometry datasets in the community. Geometry3K provides relatively sparse textual descriptions, which often lack sufficient structural information to serve as reliable seeds for our symbolic generator. In contrast, GeoQA contains rich and highly structured textual statements that implicitly encode geometric configurations and reasoning chains, for example: “In quadrilateralABCD, ∠Bis40 ◦ larger than∠A; what is the measure of∠D?” or “In△ABC, pointsDandElie onABandAC withDE ∥ BCand AD AB = 3 7 ; givenAE = 6, what is the length ofEC?” These formulations clearly expose the roles of key entities and constraints, making them suitable as structural backbones. Motivated by this observation, we propose an extended pipeline where we reuse the textual stems of existing training problems as high-level structural seeds, and then apply our instantiation and visualization stages to generate variants with concrete coordinates and diagrams. This “text-to-structure” augmentation bridges part of the domain gap by aligning the combinatorial structure of our synthetic data with that of real benchmarks, while still benefiting from automatic validation and visualization. We evaluate this approach in an out-of-distribution (OOD) setting on GeoQA, comparing three training regimes: (i)Baseline, using only the original pretrained backbones; (i)OOD, training on our original synthetic dataset; and (i)Ours, further augmenting training with text-seeded synthetic data derived from GeoQA-style problems. Results are summarized in Table 8. Overall, these results demonstrate that our solver-driven pipeline is not limited to fully synthetic symbolic seeds, but can flexibly absorb real-world textual problems as structural inputs. This extensibility enables principled adaptation to diverse geometry datasets and provides a general recipe for combining symbolic generation with existing benchmarks. F Example Data from Our Pipeline This section presents example diagrams generated by our pipeline to illustrate the types of geometric structures it produces. 21 cong perp coll eqangle para eqratio aconst simtri simtrir midp cyclic contrir rconst contri circle Predicate 10 2 10 3 10 4 10 5 Count (log scale) Predicate Frequency 56789 10111213141516171819202122232426 Number of predicates per problem 0 1000 2000 3000 4000 5000 Number of Problems Predicate Count per Problem Figure 8 Predicate statistics of generated geometry problems: predicate frequency (left) and predicate count per problem (right). Figure 8 provides statistical insights into the predicate distribution of our generated problems. The left panel shows the frequency distribution of predicates sampled during seed generation, revealing a long-tail distribution where commonly used predicates such as perpendicularity and parallelism occur with much higher probability than less frequent ones like concyclic or similarity relations. This distribution pattern demonstrates that our generation process is not a rigid template-based procedure, but rather a flexible process that naturally captures the varying frequencies of different geometric relationships in real-world problems. The right panel displays the distribution of predicate counts per problem, which follows an approximately normal distribution centered around a mean of 10 predicates. This level of structural complexity, with an average of 10 geometric constraints per problem, significantly exceeds the complexity typically found in existing geometry datasets, as can be observed in the detailed examples shown in Figure 9. Figure 9 shows 20 example diagrams from our fully synthetic dataset, while Figure 10 displays 20 example diagrams generated using the extended approach described in Appendix E(text-seeded synthesis). The diagrams in Figure 9 demonstrate the complex geometric structures that our fully synthetic pipeline can generate. These examples showcase several key characteristics of our solver-driven generation approach. First, the diagrams exhibit dense geometric constructions with multiple overlapping circles, intricate polygon configurations, and complex intersection patterns that require sophisticated spatial reasoning to fully com- prehend. Second, they feature non-trivial relational constraints including rich networks of geometric relations such as parallelism, perpendicularity, cyclic quadrilaterals, similarity constructions, and congruence relations that create multi-step reasoning chains. Third, the problems involve high entity density with numerous points, segments, and circles that have interwoven dependencies, challenging both visual perception and symbolic reasoning capabilities. The structural richness of these diagrams reflects the effectiveness of our pipeline in exploring complex geometric configurations through symbolic seed generation, dependency construction, and rigorous verification mechanisms. The diagrams in Figure 10 illustrate the output of our extended pipeline when applied to existing textual problem formulations. These examples demonstrate the compatibility and extensibility of our framework, showing that the instantiation and visualization stages can effectively process different types of input sources. By feeding textual problem statements into our pipeline, we can leverage the same verification mechanisms and visualization capabilities to produce geometrically consistent diagrams, even when the underlying structural seeds originate from existing problem formulations rather than purely symbolic generation. This flexibility highlights the modular design of our pipeline, where the instantiation and visualization components can operate independently of the seed generation stage, enabling adaptation to diverse data sources while maintaining strict geometric correctness and visual quality standards. Together, these example diagrams illustrate the range of geometric structures that our pipeline can produce, from complex solver-driven constructions to text-grounded instantiations, demonstrating both the effectiveness 22 Figure 9 Example diagrams from our fully synthetic pipeline. These 20 examples illustrate the geometric structures generated by our solver-driven pipeline, featuring dense relational constraints, multi-step constructions, and non-trivial geometric configurations. Each diagram exhibits rich structural complexity with multiple geometric entities, intricate spatial relationships, and sophisticated reasoning patterns. 23 Figure 10 Example diagrams from text-seeded synthesis (Appendix E). These 20 examples illustrate the geometric structures generated by feeding existing textual problem statements into our instantiation and visualization stages. 24 of our fully synthetic approach and the compatibility of our framework with alternative input modalities. G Detailed Pipeline and Algorithms Our complete generation pipeline is summarized in??1. In this section, we provide detailed descriptions of the coordinate verification mechanism, which ensures geometric consistency between symbolic constraints, numerical coordinates, and visual diagrams. Algorithm 1: End-to-end pipeline for synthesizing multimodal geometry problems from scratch Input: Predicate poolP; theorem libraryT ; number of sampled predicate sets N ; target/subgoal budget M ; selection rule SelectSeed(·); Instructor LLML inst ; Coder LLML code ; Semantic checker LLML sem ; quality checker ImgQC(·). Output: Final datasetD =(I, P ′ , R ′ , A, C plot ), where I is diagram, P ′ is debiased problem, R ′ is debiased CoT, A is answer, and C plot is plotting code. D ←∅ ;// final retained samples for i = 1to N do // Stage 1: Seed generation from symbolic predicates S ← SamplePredicates(P) ; // randomly sample a predicate set G← BuildDependencyGraph(S; T ) ; // dependency graph G ← ExtractSubgoals(G) ; // candidate targets/subgoals from proofs G ← FilterTrivial(G) ; // remove tautologies/degeneracies G ⋆ ← SampleSubgoals(G, M ) ; // subgoal sampling/budgeting S seed ← SelectSeed(S, G,G ⋆ ) ; // premises, steps, targets if S seed =∅ then continue // Stage 2: Instantiation by Instructor + semantic validation (P, R, A)←L inst (S seed ) ; // problem, CoT, answer ok sem ←L sem (P, R, A) ; // logical/format/consistency check ifok sem = false then continue // Stage 2 (cont.): Meta code generation + executable grounding C meta ←L code (P ) ; // meta construction code conditioned only on P ok exec ← ExecuteSandbox(C meta ) ; // safety + runtime validity ifok exec = false then continue (X, Π)← ParseMetaCode(C meta ) ; //X: coordinates; Π: plotting code/spec ok geo ← VerifyGeometry(P,X) ; // verify declared constraints numerically ok ans ← VerifyAnswer(P, A,X) ; // check metric answer via coordinates if ok geo = falseorok ans = false then continue // Stage 3: Visualization + image quality filtering C plot ← ToPlottingCode(Π) ; // serialize plotting code into plotting code DSL/JSON I ← Render(C plot ) ; // deterministic diagram rendering ok img ← ImgQC(I) ; // overlap/ambiguity/clutter checks ifok img = false then continue // Stage 3 (cont.): Textual debiasing using plotting code (P ′ , R ′ )← Debias(P, R, Π) ; // remove diagram-inferable cues; rewrite reasoning trace D ←D∪(I, P ′ , R ′ , A, C plot ) returnD. 25 G.1 Coordinate Verification Mechanism The coordinate verification stage performs numerical validation to ensure that the generated coordinates satisfy all geometric constraints declared in the problem statement. This verification is critical for maintaining consistency across symbolic structure, textual description, and visual representation. Coordinate Generation. Given a problem statementP, the Coder LLML code generates Python code that computes coordinates for all geometric entities mentioned inP. The generated code must satisfy several constraints: (1) all points must have distinct coordinates to avoid degeneracy, (2) all geometric relations (e.g., perpendicularity, parallelism, collinearity) must be explicitly enforced through numerical construction, and (3) the code must be executable in a sandboxed environment without external dependencies beyond standard mathematical libraries. The code is executed to obtain a coordinate dictionaryX =p i : (x i ,y i ), where each p i is a point label and (x i ,y i ) are its 2D coordinates. Geometric Constraint Verification. After extracting coordinatesXand plotting specificationsΠfrom the executed meta code, we perform two types of numerical checks: (1) Constraint Verification (VerifyGeometry): For each geometric relation explicitly stated in the problemP, we verify that the coordinates satisfy the corresponding numerical condition. This includes: •Length constraints: For any segmentABwith declared lengthl, we check that|∥X(A)−X(B)∥− l| < ε, where ε = 10 −6 is a numerical tolerance. •Angle constraints: For any angle∠ABCwith declared measureθ, we compute the angle using vector dot product and verify|∠(X(A),X(B),X(C))− θ| < ε. •Parallelism and perpendicularity: For parallel linesAB ∥ CD, we verify that the angle between direction vectors is withinεof0 ◦ or180 ◦ ; for perpendicular linesAB ⊥ CD, we verify the angle is withinεof90 ◦ . •Collinearity: For collinear pointsA,B,C, we verify that the area of triangleABC(computed via cross product) is within ε of zero. •Circle constraints: For a circle with centerOand radiusr, or a circle passing through pointsA,B,C, we verify that all declared points on the circle satisfy|∥X(p)−X(O)∥−r| < ε(or equivalent for three-point circles). (2) Answer Verification (VerifyAnswer): For problems with numerical answers, we evaluate the answer quan- tity using the generated coordinates. Specifically, we parse the DSL expression fromΠ.quantities(e.g., length(A, B),angle(A, B, C), or more complex expressions likelength(A, B)− length(C, D)for proof problems). The DSL supports geometric primitives including: • Point-based quantities: length(A, B), angle(A, B, C), area(A, B, C,...), perimeter(A, B, C,...). • Line-based quantities: angle_between_lines(A, B, C, D) and its trigonometric variants. • Circle-based quantities:radius(C1),arc_length(C1, A, B),sector_area(C1, A, B), etc., whereC1is a circle ID. Each DSL expression is evaluated by substituting point coordinates and circle parameters, then compared against the declared answer A with tolerance ε. For computation problems, the DSL expression directly represents the quantity to be computed (e.g.,length(A, B) for finding the length of segmentAB), and we verify that the evaluated value matches the declared answerA. For proof problems, we transform the statement to be proved into a zero-value expression for numerical verification. Specifically, if the conclusion to be proved is an equality relation (e.g., “AB = CD”, “∠ABC = ∠DEF ”, or “AB ∥ CD”), we convert it into a difference expression that should evaluate to zero: • Equality of lengths: “AB = CD”→ length(A, B)− length(C, D) • Equality of angles: “∠ABC =∠DEF ”→ angle(A, B, C)− angle(D, E, F) 26 • Parallelism: “AB ∥ CD”→ angle_between_lines(A, B, C, D)− 0 • Perpendicularity: “AB ⊥ CD”→ angle_between_lines(A, B, C, D)− 90 • Collinearity: “Points A,B,C are collinear”→ area(A, B, C)− 0 • Ratio relations: “AB : CD = EF : GH”→ length(A, B)/length(C, D)− length(E, F)/length(G, H) We then evaluate the transformed expression using the generated coordinates and verify that the result is withinεof zero, confirming that the geometric relation holds numerically. This zero-value verification approach enables rigorous validation of proof statements through coordinate-based computation, ensuring that the symbolic conclusion is consistent with the numerical instantiation. Annotation Consistency Check. Beyond constraint and answer verification, we also validate that annotations in Π.annotations are consistent with the computed coordinates: •Length annotations: For each entry[[”A”, ”B”],v]inlength_of_line, we verify that the actual length ∥X(A)−X(B)∥ matches the annotated value v (after parsing LaTeX expressions like 2 √ 3). • Right angle annotations: For each entry[”A”, ”B”, ”C”]inright_angles, we verify that∠(X(A),X(B),X(C)) = 90 ◦ ± ε. •Angle measure annotations: For each entry[[”A”, ”B”, ”C”],θ]inmeasure_of_angle, we verify that the computed angle matches θ (with appropriate unit conversion if the annotation uses radians). Samples that fail any of these verification steps are discarded, ensuring that all retained instances maintain strict numerical consistency between symbolic constraints, coordinate realizations, and visual diagrams. This multi-level validation mechanism is essential for generating high-quality geometry problems with guaranteed mathematical correctness. G.2 Plotting Code Format Specification After coordinate verification, the geometric construction is serialized into a structured plotting code format that serves as the interface between coordinate computation and diagram rendering. This format is designed to be both human-readable and machine-executable, enabling deterministic visualization while preserving all geometric information necessary for verification and reasoning. The plotting code is represented as a JSON-like dictionary structure with the following schema: Point Coordinates. The points field maps point labels to 2D coordinates: "points": "A": (xA, yA), "B": (xB, yB), ... Each coordinate pair(x i ,y i )must be a tuple or list of two numeric values (integers or floats). All points must have distinct coordinates to avoid degeneracy. Segments. The segments field lists all line segments to be drawn: "segments": [ ["A", "B"], ["B", "C"], ... ] Each segment is represented as a two-element list containing the labels of its endpoints. Segments are drawn as straight lines connecting the specified points. 27 Circles. Thecirclesfield specifies all circles in the diagram. Each circle is represented as a list with the following formats: • ["C1", "O", r]: Circle with ID C1, center at point O, and radius r (numeric value). • ["C2", "O", "P"]: Circle with ID C2, center at point O, and radius equal to the distance from O to P. • ["C3", "A", "B", "diameter"]: Circle with ID C3, where segment AB is the diameter. • ["C4", "A", "B", "C"]: Circle with ID C4 passing through three points A, B, and C. Each circle must have a unique ID (e.g.,C1,C2,C3) that is used for referencing in DSL expressions. The circle ID is distinct from point labels and is required for all circle-related geometric quantities. In the practical implementation of our code-based alignment, we simplify the regression target for circular entities. Although our data generation pipeline supports multiple construction methods for circles (e.g., via diameter or three points), we unify these into a standard center-radius format, specifically["O", r], during the model training phase. As illustrated in Figure 3, regardless of the initial construction logic, the rendering engine eventually computes a deterministic coordinate-level radius to plot the diagram. To improve the stability of structural prediction, we only require the model to regress the integer part of the radius. This design choice effectively reduces the complexity of numerical prediction while preserving the essential geometric structure required for subsequent reasoning. Annotations. Theannotationsfield contains visual markers and measurements that are explicitly stated in the problem: "annotations": "right_angles": [ ["A", "B", "C"], ... ], "length_of_line": [ [["A", "B"], "5"], [["C", "D"], "2*sqrt(3)"], ... ], "measure_of_angle": [ [["A", "B", "C"], "30"], ... ] • right_angles: List of angle triples ["A", "B", "C"] where∠ABC = 90 ◦ . • length_of_line : List of pairs[[segment], value]where the segment (two-point list) has the specified length. The value can be a numeric string (e.g., "5") or an expression (e.g., "2*sqrt(3)"). • measure_of_angle: List of pairs[[angle_triple], value]where the angle (three-point list) has the specified measure in degrees. The value can be a numeric string (e.g.,"30") or a radian expression with π (e.g., "pi/6"). All annotations must correspond to geometric relations that are explicitly stated in the problem text, not inferred through reasoning. Quantities. Thequantitiesfield contains DSL expressions representing the quantities to be computed or verified: "quantities": [ "length(A, B)", 28 "angle(A, B, C)", "length(A, B) - length(C, D)", ... ] For computation problems, each expression directly represents a quantity to be found. For proof problems, expressions take the formleft - right(e.g.,"length(A, B) - length(C, D)"), which should evaluate to zero if the statement is true. The complete plotting code structure enables deterministic rendering: given the same plotting code, the renderer produces identical diagrams. This property is crucial for maintaining consistency between the generated problem statement, the underlying geometric structure, and the visual representation, and enables plotting code to serve as an explicit supervision target for visual–symbolic alignment. G.3 Seed Generation Our seed generation process leverages GenesisGeo [34], an improved implementation of AlphaGeometry and NewClid [42], to construct symbolic geometric structures. To ensure consistency and compatibility with the underlying reasoning system, we maintain the same rule set used by GenesisGeo. These rules form the foundation of our symbolic reasoning engine and enable the construction of dependency graphs from predicate sets. The rule set we employ is identical to that used in GenesisGeo, ensuring that our generated seeds are compatible with the solver’s reasoning capabilities. These rules encode fundamental geometric relationships and theorems, allowing the system to perform forward symbolic reasoning and construct proof dependency graphs. By using the same rule set, we ensure that the symbolic structures generated in our pipeline are directly compatible with GenesisGeo’s reasoning engine, enabling seamless integration between seed generation and validation. List of rules with names: r00 Perpendiculars give parallel perp A B C D, perp C D E F, ncoll A B E => para A B E F r01 Definition of circle cong O A O B, cong O B O C, cong O C O D => cyclic A B C D r02 Parallel from inclination eqangle A B P Q C D P Q => para A B C D r03 Arc determines internal angles cyclic A B P Q => eqangle P A P B Q A Q B r04 Congruent angles are in a circle eqangle P A P B Q A Q B, ncoll P Q A B => cyclic A B P Q r05 Same arc same chord cyclic A B C P Q R, eqangle C A C B R P R Q => cong A B P Q r06 Base of half triangle midp E A B, midp F A C => para E F B C r07 Thales Theorem I para A B C D, coll O A C, coll O B D => eqratio3 A B C D O O r08 Right triangles common angle I perp A B C D, perp E F G H, npara A B E F => eqangle A B E F C D G H 29 r09 Sum of angles of a triangle eqangle a b c d m n p q, eqangle c d e f p q r u => eqangle a b e f m n r u r10 Ratio cancellation eqratio a b c d m n p q, eqratio c d e f p q r u => eqratio a b e f m n r u r11 Bisector theorem I eqratio d b d c a b a c, coll d b c, ncoll a b c => eqangle a b a d a d a c r12 Bisector theorem I eqangle a b a d a d a c, coll d b c, ncoll a b c => eqratio d b d c a b a c r13 Isosceles triangle equal angles cong O A O B, ncoll O A B => eqangle O A A B A B O B r14 Equal base angles imply isosceles eqangle A O A B B A B O, ncoll O A B => cong O A O B r15 Arc determines inscribed angles (tangent) circle O A B C, perp O A A X => eqangle A X A B C A C B r16 Same arc giving tangent circle O A B C, eqangle A X A B C A C B => perp O A A X r17 Central angle vs inscribed angle I circle O A B C, midp M B C => eqangle A B A C O B O M r18 Central angle vs inscribed angle I circle O A B C, coll M B C, eqangle A B A C O B O M => midp M B C r19 Hypothenuse is diameter perp A B B C, midp M A C => cong A M B M r20 Diameter is hypotenuse circle O A B C, coll O A C => perp A B B C r21 Cyclic trapezoid cyclic A B C D, para A B C D => eqangle A D C D C D C B r22 Bisector Construction midp M A B, perp O M A B => cong O A O B r23 Bisector is perpendicular cong A P B P, cong A Q B Q => perp A B P Q r24 Cyclic kite cong A P B P, cong A Q B Q, cyclic A B P Q => perp P A A Q r25 Diagonals of parallelogram I midp M A B, midp M C D => para A C B D r26 Diagonals of parallelogram I midp M A B, para A C B D, para A D B C => midp M C D r27 Thales theorem I eqratio O A A C O B B D, coll O A C, coll O B D, ncoll A B C, sameside A O C B O D => para A B C D 30 r28 Overlapping parallels para A B A C => coll A B C r29 Midpoint is an eqratio midp M A B, midp N C D => eqratio M A A B N C C D r30 Right triangles common angle I eqangle A B P Q C D U V, perp P Q U V => perp A B C D r31 Denominator cancelling eqratio A B P Q C D U V, cong P Q U V => cong A B C D r34 A Similarity of triangles (direct) eqangle B A B C Q P Q R, eqangle C A C B R P R Q, ncoll A B C, sameclock A B C P Q R => simtri A B C P Q R r35 A Similarity of triangles (reverse) eqangle B A B C Q R Q P, eqangle C A C B R Q R P, ncoll A B C, sameclock A B C P R Q => simtrir A B C P Q R r36 ASA Congruence of triangles (direct) eqangle B A B C Q P Q R, eqangle C A C B R P R Q, ncoll A B C, cong A B P Q, sameclock A B C P Q R => contri A B C P Q R r37 ASA Congruence of triangles (reverse) eqangle B A B C Q R Q P, eqangle C A C B R Q R P, ncoll A B C, cong A B P Q, sameclock A B C P R Q => contrir A B C P Q R r41 Thales theorem I para a b c d, coll m a d, coll n b c, eqratio m a m d n b n c, sameside m a d n b c => para m n a b r42 Thales theorem IV para a b c d, coll m a d, coll n b c, para m n a b => eqratio m a m d n b n c r43 Orthocenter theorem perp a b c d, perp a c b d => perp a d b c r44 Pappus ’s theorem coll a b c, coll p q r, coll x a q, coll x p b, coll y a r, coll y p c, coll z b r, coll z c q => coll x y z r45 Simson ’s line theorem cyclic a b c p, coll a l c, perp p l a c, coll m b c, perp p m b c, coll n a b, perp p n a b => coll l m n r46 Incenter theorem eqangle a b a x a x a c, eqangle b a b x b x b c, ncoll a b c => eqangle c b c x c x c a r47 Circumcenter theorem midp m a b, perp x m a b, midp n b c, perp x n b c, midp p c a => perp x p c a r48 Centroid theorem midp m a b, coll m x c, midp n b c, coll n x a, midp p c a => coll x p b r49 Recognize center of cyclic (circle) circle O A B C, cyclic A B C D => cong O A O D 31 r50 Recognize center of cyclic (cong) cyclic A B C D, cong O A O B, cong O C O D, npara A B C D => cong O A O C r51 Midpoint splits in two midp M A B => rconst M A A B 1/2 r52 Properties of similar triangles (Direct) simtri A B C P Q R => eqangle B A B C Q P Q R, eqratio B A B C Q P Q R r53 Properties of similar triangles (Reverse) simtrir A B C P Q R => eqangle B A B C Q R Q P, eqratio B A B C Q P Q R r54 Definition of midpoint cong M A M B, coll M A B => midp M A B r55 Properties of midpoint (cong) midp M A B => cong M A M B r56 Properties of midpoint (coll) midp M A B => coll M A B r57 Pythagoras theorem PythagoreanPremises a b c => PythagoreanConclusions a b c r58 Same chord same arc I cyclic a b c p q r, cong a b p q, sameclock c a b r p q, sameside c a b r p q => eqangle c a c b r p r q r59 Same chord same arc I cyclic a b c p q r, cong a b p q, sameclock c b a r p q, nsameside c b a r p q => eqangle c a c b r q r p r60 S Similarity of triangles (Direct) eqratio B A B C Q P Q R, eqratio C A C B R P R Q, ncoll A B C, sameclock A B C P Q R => simtri A B C P Q R r61 S Similarity of triangles (Reverse) eqratio B A B C Q P Q R, eqratio C A C B R P R Q, ncoll A B C, sameclock A B C P R Q => simtrir A B C P Q R r62 SAS Similarity of triangles (Direct) eqratio B A B C Q P Q R, eqangle B A B C Q P Q R, ncoll A B C, sameclock A B C P Q R => simtri A B C P Q R r63 SAS Similarity of triangles (Reverse) eqratio B A B C Q P Q R, eqangle B A B C Q P Q R, ncoll A B C, sameclock A B C P R Q => simtrir A B C P Q R r64 S Congruence of triangles (Direct) cong A B P Q, cong B C Q R, cong C A R P, ncoll A B C, sameclock A B C P Q R => contri A B C P Q R r65 S Congruence of triangles (Reverse) cong A B P Q, cong B C Q R, cong C A R P, ncoll A B C, sameclock A B C P R Q => contrir A B C P Q R r66 SAS Congruence of triangles (Direct) 32 cong A B P Q, cong B C Q R, eqangle B A B C Q P Q R, ncoll A B C, sameclock A B C P Q R => contri A B C P Q R r67 SAS Congruence of triangles (Reverse) cong A B P Q, cong B C Q R, eqangle B A B C Q P Q R, ncoll A B C, sameclock A B C P R Q => contrir A B C P Q R r68 Similarity without scaling (Direct) eqratio B A B C Q P Q R, eqratio C A C B R P R Q, ncoll A B C, cong A B P Q, sameclock A B C P Q R => contri A B C P Q R r69 Similarity without scaling (Reverse) eqratio B A B C Q P Q R, eqratio C A C B R P R Q, ncoll A B C, cong A B P Q, sameclock A B C P R Q => contrir A B C P Q R H API Usage In section 4.3, we evaluated the difficulty of our generated problems using closed-source large language model APIs. Specifically, we accessed Google’s Gemini-2.5-Pro and OpenAI’s GPT-5 through the OpenRouter API, while Qwen3-VL-32B-Thinking was served locally. Throughout the evaluation process, we ensured that both the system prompt and user prompt remained consistent across all models to guarantee fair and correct assessment. I Limitations Although our method successfully synthesizes geometric data, it still has several limitations. Dependence on LLM Reasoning Capabilities. First, during instantiation, our approach heavily relies on the reasoning capabilities of existing LLMs. We use GPT-OSS-120B as the reasoning model, and approximately 50% of samples are discarded during this process. We believe that using stronger reasoning models in the future can improve this efficiency. Additionally, methods relying on LLMs inevitably face hallucination issues, and validating their results requires additional computational overhead. Model-Specific Evaluation. Second, our experiments are primarily conducted on the Qwen series of models, such as Qwen2.5VL and Qwen3VL. While our approach can theoretically be directly transferred to other VLM backbones, we have not extensively validated this transferability. We also look forward to our data being used for training other series of VLMs. Geometric Scope and Visual Style. Finally, our constructed geometry is limited to planar Euclidean geometry. This limitation stems from the structural foundation generated during the Seed Generation stage, which is inherently planar. Our work does not cover higher-dimensional geometric types, which represents a direction for future research. Additionally, the images we generate are idealized and presented in a textbook style, and therefore do not cover handwritten, sketch, or real exam paper styles. J Prompts LLM Generator Prompt (Computation) You are a professional geometry problem authoring expert, proficient in Euclidean plane geometry and competition-level geometry problems (such as AMC / AIME / Math Olympiad). [Task Objective] 33 Based on the input <problem> (geometric premises) and conclusion, you need to: 1. Understand the geometric configuration described (points, line segments, perpendicular, parallel, equal lengths, similarity, collinearity, etc.). 2. On the basis of this geometric configuration, design a high-quality, high-difficulty numerical geometry problem (with only one solving target). 3. Provide a complete problem statement, detailed reasoning process (CoT), and the final numerical answer. The problem statement should use "geometric language" only, do not use coordinate systems. -------------------------------- [Problem Requirements] 1. **Numerical Settings** - Set reasonable numerical values for side lengths, angles, ratios, etc. (recommended: integers or simple fractions in the range 2-20, e.g., 3/2, 5/3). - The answer should not be too simple (avoid obvious results like 0, 1, 2; avoid cases where the answer is identical to a given quantity). 2. **Solving Target Type (only one)** The problem should end with a single solving target, ending with "Find...". It can be: - The length of a line segment; - The degree measure of an angle or its trigonometric value; - The ratio of two line segments; - The area / perimeter of a triangle or quadrilateral; - Angles, arc lengths, areas involving circles; - Arithmetic operations on the above quantities (e.g., AB 2 + AC 2 , area ratios). 3. **Geometric Logic Requirements** - The problem must be logically self-consistent, non-contradictory, and have a unique solution. - Degenerate cases are not allowed (e.g., three collinear points forming a triangle). - If new points are introduced (e.g., intersection points, foots of perpendiculars, midpoints), they must be clearly defined. 4. **Problem Statement Format** - Natural language narrative, using LaTeX mathematical notation (e.g., AB, angleABC, S_triangleABC). - Do not include reasoning content like conclusion, only include construction content. - The last sentence should end with "Find...". 5. **CoT Reasoning Process** - Write in Step1 / Step2 / Step3... format. - Use LaTeX mathematical notation and formulas. - Do not mention DSL, <problem>, symbolic propositions, etc., only reason based on the problem statement. 6. **Answer Format** - "answer": Only provide the final numerical value or expression, e.g., "15/2", "5sqrt3". - Do not include explanatory text. -------------------------------- [Input Format] <problem> problem </problem> <conclusion> conclusion </conclusion> aux_section [Output Format] 34 Output only a JSON object: "question": "(Problem statement using LaTeX math notation)", "cot": "Step1 ... 2 ... 3 ...", "answer": "(Final numerical result, only provide value or expression)" 35 LLM Generator Prompt (Proof) You are a professional geometry problem authoring expert, proficient in Euclidean plane geometry and competition-level geometry problems (such as AMC / AIME / Math Olympiad). [Task Objective] Based on the input <problem> (geometric premises) and <conclusion> (the conclusion to be proved), you need to: 1. Understand the geometric configuration described (points, line segments, perpendicular, parallel, equal lengths, similarity, collinearity, etc.). 2. Convert the symbolic geometric premises and conclusion into a natural language geometry proof problem. 3. Provide a complete problem statement, detailed proof process (CoT), and proof conclusion. The problem statement should use "geometric language" only, do not use coordinate systems. -------------------------------- [Problem Requirements] 1. **Problem Statement Construction** - Convert the premises in <problem> into natural language descriptions. - Convert the conclusion in <conclusion> into a natural language proof goal. - You may add auxiliary conditions in the problem statement (such as midpoints, angle bisectors, division points, etc.), but they must be reasonable and compatible with the geometric structure in <problem>. - Do not introduce new "unknown quantities" or additional parameters (such as new variables x, y, t, k, etc.) in the problem statement and proof process. If quantity relationships need to be expressed, use known quantities (side lengths, angles, ratios given in the problem) or their combinations directly. 2. **Proof Goal** - The problem should end with "Prove that..." to clearly state the geometric conclusion to be proved. - The proof goal can be: - Two line segments are equal or proportional; - Two angles are equal or proportional; - Certain points are collinear or concyclic; - Certain lines are parallel or perpendicular; - Certain triangles are similar or congruent; - Other geometric relationships. 3. **Geometric Logic Requirements** - The problem must be logically self-consistent, non-contradictory, and provable. - Degenerate cases are not allowed (e.g., three collinear points forming a triangle). - If new points are introduced (e.g., intersection points, foots of perpendiculars, midpoints), they must be clearly defined. - The premises must be sufficient to derive the conclusion. 4. **Problem Statement Format** - Natural language narrative in Chinese, using LaTeX mathematical notation (e.g., AB, angleABC, S_triangleABC). - Do not include reasoning content like conclusion, only include construction content and proof goal. - The last sentence should end with "Prove that...". 5. **CoT Proof Process** - Write the complete proof process in Step1 / Step2 / Step3... format. - Use LaTeX mathematical notation and formulas. 36 - Each step should explain the geometric theorem or property used (such as congruence, similarity, parallel line properties, circle properties, etc.). - Do not mention DSL, <problem>, symbolic propositions, etc., only perform geometric reasoning based on the problem statement. - The proof process should be logically clear and complete. 6. **Answer Format** - "answer": Provide the proof conclusion, formatted as "QED" or "Therefore, [conclusion]". - If the conclusion involves quantity relationships, express the conclusion directly using known quantities or their combinations, do not introduce additional unknown quantities. -------------------------------- [Input Format] <problem> problem </problem> <conclusion> conclusion </conclusion> aux_section [Output Format] Output only a JSON object: "question": "(Problem statement using LaTeX math notation, ending with ’Prove that...’)", "cot": "Step1 ... 2 ... 3 ...", "answer": "(Proof conclusion, e.g., ’QED’ or ’Therefore, [conclusion]’)" 37 LLM Plotter Prompt (Coordinates) Your task is: Generate a set of 2D numerical coordinates for all points appearing in the problem that satisfy all geometric relationships in the problem statement, making the figure structure reasonable, clear, and stable. ===================== [Problem Text] question ===================== Please output a piece of **executable Python code** that strictly satisfies the following requirements: ===================================================== [Global Code Constraints] ===================================================== 1. You must generate **complete, executable Python code**, do not output explanations, comments, or extra text. 2. All variables, functions, and constants must be explicitly defined or imported in the code. 3. All coordinates must be **concrete numerical values (float or int)**, do not use symbolic expressions, lambdas, undefined variables, or lazy expressions. 4. Standard library imports are allowed (e.g., ‘import math‘, ‘import numpy‘), but file I/O and network requests are prohibited. ===================================================== [Geometric Construction Rules] ===================================================== 1. **Point Name Restrictions**: Only use points mentioned in the problem statement, do not introduce any new points. 2. **Geometric Relationship Constraints**: Coordinates must satisfy all geometric relationships appearing in the problem statement, for example: - Perpendicular, parallel - Collinear - Midpoint - On circle - Ratio relationships - Equal lengths - ... Do not add properties not mentioned in the problem (such as isosceles, perpendicular, parallel, etc.). 3. **Non-degenerate Figure**: - Do not allow two different points to coincide - Do not allow three points that should form an angle/triangle to be nearly collinear - Coordinates should be dispersed and stable 4. Geometric relationships must be guaranteed to hold through explicit construction (e.g., through slope, vectors, distance from point to circle center, etc.). ===================================================== [Final Output Structure] ===================================================== At the end of the code, construct and print the following dictionary. The dictionary should only contain point coordinates, do not include any other content (field names must match exactly): result = "points": # Coordinate mapping for all points "A": (xA, yA), "B": (xB, yB), ... 38 import json print(json.dumps(result, ensure_ascii=False)) You must output only Python code, do not include any explanatory text or non-code content. 39 LLM Plotter Prompt (Annotations) Your task is: Extract annotation information (annotations), line segments (segments), and circles (circles) based only on "conditions directly stated in text" in the problem statement. Do not add any implicitly inferred information. ===================== [Problem Text] question ===================== Please directly output a JSON object containing the following fields: "segments": [ ["A", "B"], ["B", "C"], ... ], "circles": [ ["C1", "O", 5], ["C2", "A", "B", "diameter"], ["C3", "A", "B", "C"], ... ], "annotations": "right_angles": [ ["A", "B", "C"], ... ], "length_of_line": [ [["A", "B"], "5"], [["C", "D"], "2*sqrt(3)"], ... ], "measure_of_angle": [ [["A", "B", "C"], "30"], ... ] [Extraction Rules] 1. segments (line segments): - If the problem describes a polygon (e.g., triangle ABC, quadrilateral ABCD, etc.), you must include all edges of the polygon in segments, do not miss any edges. - If the problem implicitly mentions an edge, also include it in segments. - If the problem explicitly mentions a line segment or edge (e.g., "connect AD", "draw BE"), the corresponding segment should also appear in segments. - Segment format: ["A", "B"] represents a line segment with endpoints A and B. 2. circles: - Unless the problem **explicitly mentions "circle", "inscribed circle", "circumscribed circle" or similar descriptions**, circles must be an empty array []. - If the problem involves circles, each circle must use a **unique circle ID**: C1, C2, C3, ... - Circle formats: ["C1", "O", 5] # Circle C1, center O, radius 5 ["C2", "O", "P"] # Circle C2, center O, OP as radius 40 ["C3", "A", "B", "diameter"] # Circle C3, AB as diameter ["C4", "A", "B", "C"] # Circle C4, passing through A, B, C 3. annotations: Only annotate geometric quantities **directly stated in the problem text**, do not add information inferred through reasoning. Allowed annotation examples: - Angles and lengths should only be annotated with numbers. - If the problem states "angleABC = 30degrees", you can record in ‘measure_of_angle‘: [["A", "B", "C"], "30"] - If the problem states "AB = 5" or "AB = 2sqrt3", you can record in ‘length_of_line‘: [["A", "B"], "5"] or [["A", "B"], "2*sqrt(3)"] - If the problem states "angleABC is a right angle" or "angleABC = 90degrees", you can record in ‘right_angles‘: ["A", "B", "C"] Explicitly prohibited: - Do not annotate information "inferred" from geometric properties, for example: - If a triangle is isosceles, do not add "base angles are equal"; - If a point is a midpoint, do not add "two segments are equal"; - If some edges are parallel, do not add "corresponding angles are equal", etc. - If it’s a square, do not annotate four right angles. - If the problem does not directly give numerical or right angle information, do not annotate, **prefer less than wrong**. Format requirements: - ‘right_angles‘: Elements are three-point lists ["A", "B", "C"], representing angleABC is a right angle. - ‘length_of_line‘: Elements are [ ["A", "B"], "expression string" ]. - Use ‘sqrt(x)‘ form for square roots in expressions, e.g., "2*sqrt(3)", do not use ‘math.sqrt(3)‘. - For simple integers or fractions, you can directly write strings "5", "3/2", etc. - ‘measure_of_angle‘: Elements are [ ["A", "B", "C"], "angle measure (default unit is degrees)" ], e.g., "30". - If a certain type of information does not appear in the problem at all, set the corresponding field to an empty array []. Please directly output JSON, do not include any other explanatory text. 41 LLM Plotter Prompt (Quantities - Computation) Your task is: Based on "what the problem asks you to find" in the problem, generate DSL expressions in the quantities list (do not calculate, do not output specific numerical answers). ===================== [Problem Text] question ===================== Please directly output a JSON object in the following format: "quantities": [ "length(A, B)", "angle(A, B, C)", ... ] [quantities Generation Rules (extremely important)] 1. Each element in the quantities list must be a string containing a **DSL expression**, representing "what the problem asks you to find". **Only write expressions, not numerical values**. 2. Only the following DSL forms are allowed, do not invent new function names or syntax. Special note: The first parameter of circle-related functions must be a circle ID (e.g., C1), **do not write point names (e.g., E)**, for example: - Correct: ‘radius(C1)‘ - Wrong: ‘radius(E)‘ (E is a point name, not a circle ID) (1) Point-related geometric quantities: length(A, B) # Find the length of line segment AB angle(A, B, C) # Find the measure of angleABC (default unit is degrees) tan(A, B, C) # Find the tangent value of angleABC sin(A, B, C) # Find the sine value of angleABC cos(A, B, C) # Find the cosine value of angleABC area(A, B, C, D, ...) # Find the area of polygon A-B-C-D-... perimeter(A, B, C, D, ...)# Find the perimeter of polygon A-B-C-D-... (2) Angles and trigonometric functions between two lines: angle_between_lines(A, B, C, D) # Find the angle measure between lines # AB and CD (0degrees~90degrees) tan_between_lines(A, B, C, D) # Find the tangent of the angle between # lines AB and CD sin_between_lines(A, B, C, D) # Find the sine of the angle between # lines AB and CD cos_between_lines(A, B, C, D) # Find the cosine of the angle between # lines AB and CD # Where AB represents the first line, CD represents the second line; # A, B, C, D are all points appearing in the problem. (3) Circle-related quantities (must explicitly write circle ID as the first parameter, e.g., C1, C2, do not use circle center point names or other symbols): central_angle(C1, A, B) # Find the central angle measure in circle # C1 with center as vertex, passing # through arc AB arc_length(C1, A, B) # Find the length of arc AB on circle C1 sector_area(C1, A, B) # Find the sector area in circle C1 # corresponding to arc AB arc_inscribed_angle(C1, A, B) # Find the inscribed angle measure in # circle C1 corresponding to arc AB 42 circle_area(C1) # Find the area of circle C1 circle_perimeter(C1) # Find the perimeter of circle C1 segment_area(C1, A, B) # Find the segment area in circle C1 # corresponding to chord AB radius(C1) # Find the radius of circle C1 diameter(C1) # Find the diameter of circle C1 3. **Usually, the problem asks for only one quantity, so quantities should contain only one expression**; if the problem asks for multiple quantities, you can write multiple expressions in quantities. 4. Do not calculate the values of these expressions, and do not write numerical results into quantities, only write DSL expressions as strings. 5. Simple arithmetic operations are allowed in a string (if the problem indeed requires it), for example: "length(A, B) +-*/ length(B, C)" But they must use the above basic predicates as atomic units, and the form must be clear and easy to parse. 6. **If the problem asks for a square (e.g., "find AB 2 ", "find the square of AB"), it can be expressed as a product form**, for example: "length(A, B) * length(A, B)" # Represents the square of AB Or use multiplication operators to represent the square relationship. Please directly output JSON, do not include any other explanatory text. 43 LLM Plotter Prompt (Quantities - Proof) Your task is: Based on the "prove" conclusion in the problem, generate DSL expressions in the quantities list for numerical verification. ===================== [Problem Text] question ===================== Please directly output a JSON object in the following format: "quantities": [ "length(A, B) - length(C, D)", "angle(A, B, C) - angle(D, E, F)", ... ] [quantities Generation Rules (for proof problems, extremely important)] 1. Each element in the quantities list must be a string containing a **DSL expression**, representing an equality relationship to be verified. 2. **Key points**: - For proof problems, you need to convert the "prove" conclusion into **equality verification expressions** in the format ‘left - right‘, expecting the result to be 0; - **The first parameter of all circle-related functions (such as central_angle / arc_length / sector_area / arc_inscribed_angle / circle_area / circle_perimeter / segment_area / radius / diameter) must be a circle ID (e.g., C1, C2), do not write circle center point names or other symbols**. Examples: - If the conclusion is "AB = CD", write: ‘"length(A, B) - length(C, D)"‘ - If the conclusion is "angleABC = angleDEF", write: ‘"angle(A, B, C) - angle(D, E, F)"‘ - If the conclusion is "AB:CD = EF:GH", write: ‘"length(A, B) / length(C, D) - length(E, F) / length(G, H)"‘ - If the conclusion is "AB parallel CD" (parallel), write: ‘"angle_between_lines(A, B, C, D) - 0"‘ - If the conclusion is "AB perpendicular CD" (perpendicular), write: ‘"angle_between_lines(A, B, C, D) - 90"‘ - If the conclusion is "points A, B, C are collinear", write: ‘"area(A, B, C) - 0"‘ 3. Only the following DSL forms are allowed, do not invent new function names or syntax. Special note: The first parameter of circle-related functions must be a circle ID (e.g., C1), **do not write point names (e.g., E)**, for example: - Correct: ‘radius(C1)‘ - Wrong: ‘radius(E)‘ (E is a point name, not a circle ID) (1) Point-related geometric quantities: length(A, B) # Find the length of line segment AB angle(A, B, C) # Find the measure of angleABC (default unit is degrees) tan(A, B, C) # Find the tangent value of angleABC sin(A, B, C) # Find the sine value of angleABC cos(A, B, C) # Find the cosine value of angleABC area(A, B, C, D, ...) # Find the area of polygon A-B-C-D-... perimeter(A, B, C, D, ...)# Find the perimeter of polygon A-B-C-D-... (2) Angles and trigonometric functions between two lines: angle_between_lines(A, B, C, D) # Find the angle measure between lines 44 # AB and CD (0degrees~90degrees) tan_between_lines(A, B, C, D) # Find the tangent of the angle between # lines AB and CD sin_between_lines(A, B, C, D) # Find the sine of the angle between # lines AB and CD cos_between_lines(A, B, C, D) # Find the cosine of the angle between # lines AB and CD # Where AB represents the first line, CD represents the second line; # A, B, C, D are all points appearing in the problem. (3) Circle-related quantities (must explicitly write circle ID as the first parameter, e.g., C1, C2, do not use circle center point names or other symbols): central_angle(C1, A, B) # Find the central angle measure in circle # C1 with center as vertex, passing # through arc AB arc_length(C1, A, B) # Find the length of arc AB on circle C1 sector_area(C1, A, B) # Find the sector area in circle C1 # corresponding to arc AB arc_inscribed_angle(C1, A, B) # Find the inscribed angle measure in # circle C1 corresponding to arc AB circle_area(C1) # Find the area of circle C1 circle_perimeter(C1) # Find the perimeter of circle C1 segment_area(C1, A, B) # Find the segment area in circle C1 # corresponding to chord AB radius(C1) # Find the radius of circle C1 diameter(C1) # Find the diameter of circle C1 3. If the conclusion involves multiple equality relationships, you can write multiple expressions in quantities, each expression corresponding to an equality to be verified. 4. Do not calculate the values of these expressions, and do not write numerical results into quantities, only write DSL expressions as strings. 5. Simple arithmetic operations are allowed in a string, for example: "length(A, B) - length(C, D)" "angle(A, B, C) - angle(D, E, F)" "length(A, B) / length(C, D) - length(E, F) / length(G, H)" But they must use the above basic predicates as atomic units, and the form must be clear and easy to parse. Please directly output JSON, do not include any other explanatory text. 45 LLM Plotter Prompt (Unified) You now have **three tasks** that need to be completed in **one complete, executable Python code** (do not split into multiple code segments): Task1 (Geometric Construction): Generate 2D numerical coordinates for all points appearing in the problem that satisfy the geometric relationships in the problem statement, and provide necessary line segment / circle information, making the figure structure reasonable and stable. Task2 (Plain Text Annotations): Generate annotations based only on "conditions directly stated in text" in the problem statement (do not add any implicitly inferred information). Task3 (Quantities DSL): Based on "what the problem asks you to find" in the problem, only generate DSL expressions in the quantities list (do not calculate, do not output specific numerical answers). ===================== [Problem Text] question ===================== Please output a piece of **executable Python code** that strictly satisfies the following requirements: [Global Code Constraints] 1. The code must have no syntax errors and can be directly executed in a Python interpreter. 2. All variables, constants, and functions used must be defined or imported beforehand, do not use undefined names. 3. You can use any legal method for numerical calculations (including math, fractions, numpy, etc.), but: - All point coordinates and circle radii written to result must be numerical values (int or float), **cannot** be symbolic expressions or lazy expressions. 4. The code **prohibits calculating the final answer required by the problem**, and **prohibits printing or outputting any answer numerical values**. quantities can only be DSL expressions in string form. 5. Standard library imports are allowed (e.g., ‘import math‘, ‘import json‘), but file I/O and network requests are prohibited. [Geometric Construction Rules (Task1)] 1. Points (points) - Only use point names appearing in the problem statement (e.g., A, B, C, D, O, etc.), **do not introduce any new points**. - Each point’s coordinates must be in numerical form ‘(x, y)‘, where x, y are int or float. - Do not allow two different points to coincide, i.e., different points must have different coordinates. - Coordinates can be chosen arbitrarily, but must ensure they satisfy the geometric relationships in the problem statement (such as perpendicular, parallel, collinear, on circle, etc.). 2. Line Segments (segments) - The segment list is used to describe the basic edge structure of the figure. - If the problem describes a polygon (e.g., triangle ABC, quadrilateral ABCD, etc.), you must include all edges of the polygon in segments, do not miss any edges. - Segments are stored as tuples ("A", "B"), representing a line segment 46 with endpoints A and B. - If the problem explicitly mentions a line segment or edge (e.g., "connect AD", "draw BE"), the corresponding segment should also appear in segments, as long as it does not conflict with "prohibiting introducing new points". 3. Circles (circles) - Unless the problem **explicitly mentions "circle", "inscribed circle", "circumscribed circle" or similar descriptions**, then: - ‘circles‘ must be an empty list ‘[]‘. - If the problem involves circles, each circle must use a **unique circle ID**: C1, C2, C3, ... - Allowed circle representation formats (the first parameter must be a circle ID string): ["C1", "O", 5] # Circle C1, center O, radius 5 ["C2", "O", "P"] # Circle C2, center O, OP as radius ["C3", "A", "B", "diameter"] # Circle C3, AB as diameter ["C4", "A", "B", "C"] # Circle C4, passing through A, B, C - If the problem mentions "inscribed circle", "circle determined by three points" and similar situations, prefer using three-point circle or diameter circle forms. - Do not generate additional circles not mentioned in the problem. [annotations Generation Rules (Task2)] Only annotate geometric quantities **directly stated in the problem text**, do not add information inferred through reasoning. Including but not limited to: 1. Allowed annotation examples: - If the problem states "angleABC = 30degrees", you can record in ‘measure_of_angle‘: [["A", "B", "C"], "30"] - If the problem states "AB = 5" or "AB = 2sqrt3", you can record in ‘length_of_line‘: [["A", "B"], "5"] or [["A", "B"], "2*sqrt(3)"] - If the problem states "angleABC is a right angle" or "angleABC = 90degrees", you can record in ‘right_angles‘: ["A", "B", "C"] 2. Explicitly prohibited: - Do not annotate information "inferred" from geometric properties, for example: - If a triangle is isosceles, do not add "base angles are equal"; - If a point is a midpoint, do not add "two segments are equal"; - If some edges are parallel, do not add "corresponding angles are equal", etc. - If the problem does not directly give numerical or right angle information, do not annotate, **prefer less than wrong**. 3. Format requirements: - ‘right_angles‘: Elements are three-point lists ["A", "B", "C"], representing angleABC is a right angle. - ‘length_of_line‘: Elements are [ ["A", "B"], "expression string" ]. - Use ‘sqrt(x)‘ form for square roots in expressions, e.g., "2*sqrt(3)", do not use ‘math.sqrt(3)‘. - For simple integers or fractions, you can directly write strings "5", "3/2", etc. - ‘measure_of_angle‘: Elements are [ ["A", "B", "C"], "angle measure (default unit is degrees)" ], e.g., "30". - If a certain type of information does not appear in the problem at all, set the corresponding field to an empty list ‘[]‘. 4. Do not annotate decimal lengths or angles (i.e., decimals not explicitly given in the problem, do not add extra annotations). 47 [quantities Generation Rules (Task3, extremely important)] 1. Each element in the quantities list must be a string containing a **DSL expression**, representing "what the problem asks you to find". **Only write expressions, not numerical values**. 2. Only the following DSL forms are allowed, do not invent new function names or syntax. (1) Point-related geometric quantities: length(A, B) # Find the length of line segment AB angle(A, B, C) # Find the measure of angleABC (default unit is degrees) tan(A, B, C) # Find the tangent value of angleABC sin(A, B, C) # Find the sine value of angleABC cos(A, B, C) # Find the cosine value of angleABC area(A, B, C, D, ...) # Find the area of polygon A-B-C-D-... perimeter(A, B, C, D, ...)# Find the perimeter of polygon A-B-C-D-... (2) Angles and trigonometric functions between two lines (new): angle_between_lines(A, B, C, D) # Find the angle measure between lines # AB and CD (0degrees~90degrees) tan_between_lines(A, B, C, D) # Find the tangent of the angle between # lines AB and CD sin_between_lines(A, B, C, D) # Find the sine of the angle between # lines AB and CD cos_between_lines(A, B, C, D) # Find the cosine of the angle between # lines AB and CD # Where AB represents the first line, CD represents the second line; # A, B, C, D are all points appearing in the problem. (3) Circle-related quantities (must explicitly write circle ID as the first parameter): central_angle(C1, A, B) # Find the central angle measure in circle # C1 with center as vertex, passing # through arc AB arc_length(C1, A, B) # Find the length of arc AB on circle C1 sector_area(C1, A, B) # Find the sector area in circle C1 # corresponding to arc AB arc_inscribed_angle(C1, A, B) # Find the inscribed angle measure in # circle C1 corresponding to arc AB circle_area(C1) # Find the area of circle C1 circle_perimeter(C1) # Find the perimeter of circle C1 segment_area(C1, A, B) # Find the segment area in circle C1 # corresponding to chord AB radius(C1) # Find the radius of circle C1 diameter(C1) # Find the diameter of circle C1 3. If the problem asks for only one quantity, quantities should contain only one expression; if the problem asks for multiple quantities, you can write multiple expressions in quantities. 4. Do not directly calculate the values of these expressions in the code, and do not write numerical results into quantities, only write DSL expressions as strings. 5. Simple arithmetic operations are allowed in a string (if the problem indeed requires it), for example: "length(A, B) + length(B, C)" But they must use the above basic predicates as atomic units, and the form must be clear and easy to parse. [Final Output Structure] Please construct and print the following dictionary object at the end of the code (field names and structure must match exactly): result = 48 "points": # Coordinate mapping for all points "A": (xA, yA), "B": (xB, yB), # ... , "segments": [ ("A", "B"), ("B", "C"), # ... ], "circles": [ # Each circle must use a Ci ID # ["C1", "O", 5], # ["C2", "A", "B", "diameter"], # ["C3", "A", "B", "C"], ], "quantities": [ # Only DSL expression strings appear, no numerical answers # "length(A, B)", # "angle(A, B, C)", # "angle_between_lines(A, B, C, D)", # "central_angle(C1, A, B)", # ... ], "annotations": "right_angles": [ ["A", "B", "C"], # ... ], "length_of_line": [ [["A", "B"], "5"], [["C", "D"], "2*sqrt(3)"], # ... ], "measure_of_angle": [ [["A", "B", "C"], "30"], # ... ] , import json print(json.dumps(result, ensure_ascii=False)) 49 LLM Judge Prompt You are a professional geometry problem correctness verification expert. Your task: Determine whether the problem is **mathematically self-consistent**, **conditions are complete**, and **solvable**. Input as follows: Problem: question Solution process: cot Answer: answer [Evaluation Criteria] Please judge based only on the following two points: 1. **Correctness**: Is the problem description self-consistent, with no contradictions or logical conflicts? 2. **Solvability**: Are the conditions sufficient to derive the answer? And determine whether cot and answer are consistent with the problem. [Output] Please output strict JSON, do not add any extra text: "passed": true/false, "reason": "1-2 sentences explaining the core reason" 50 LLM Judge Prompt (Plotting Code) Evaluate the quality of plotting code. Check: DSL correctness, completeness, consistency, drawability, reasonableness. Problem: question Plotting code: "dsl": "dsl", "segments": segments_json, "circles": circles_json Output JSON (only JSON, no other text): "passed": true/false, "reason": "Evaluation reason (brief explanation, 1-2 sentences)", "score": 0-100 51 VisualizeQA Prompt (Step 1: Text Simplification) You are a professional mathematics editor. Your task is to rewrite a geometry problem statement into a **concise, natural, and fluent** version. Output uses LaTeX format. **Core Assumption (must follow):** This problem comes with a perfect geometric figure. **All point existence, positional relationships, and topological structure (who intersects with whom, who is on whom, who is collinear with whom) are clearly visible in the figure.** Therefore, any descriptions in the text used to **define point positions** are redundant and **must be deleted**, even if this makes a point appear "undefined" in the text. 1. **Delete (Visual/Topological Definitions)**: - Intersection definitions: e.g., "point G is the intersection of lines AB and CD", "intersect at point P" -> delete. - Position descriptions: e.g., "point D is on side BC", "A, B, C are collinear", "as shown in the figure", "in the plane" -> delete. - Construction processes: e.g., "draw segment AD", "connect BD" -> delete. 2. **Retain (Geometric Constraints/Metrics)**: - Metrics: numerical values (lengths, angles, areas), ratios. - Relationships: parallel ( ), perpendicular ( ), equality (=). - Implicit metric high-level properties: must retain "midpoint" (implies 1:1), "angle bisector" (implies equal angles), "tangent", "regular polygon", "diameter", etc. 3. **Rewrite (Natural Flow)**: - Use "given", "satisfy", "where", "and" to connect remaining conditions. - Keep sentences fluent, do not write as broken keyword lists. - **Maintain LaTeX format for all mathematical symbols** **Example Learning (Few-Shot)**: Example 1 (Delete intersection definition) Input: Given $AB=3$, $AC=6$, $ BAC=90 $, point $D$ is the midpoint of $AB$, point $G$ is the intersection of $CD$ and $AE$. Find the length of $GD$. Output: Given $AB=3$, $AC=6$, $ BAC=90 $, and $D$ is the midpoint of $AB$. Find the length of $GD$. Example 2 (Delete construction and collinearity) Input: Given points $A$, $B$, $C$, $D$ in the plane, satisfying $AB CD$, $AB = CD = 4$. Connect $AC$ and $BD$ intersecting at point $O$. If $A$, $O$, $C$ are collinear, find the value of $ AOOC$. Output: Given $AB CD$, and $AB = CD = 4$. Find the value of $ AOOC$. Example 3 (Retain circle and tangent) Input: As shown, $PA$, $PB$ are tangents to circle $O$, with points of tangency $A$, $B$ respectively. Line $PO$ intersects circle $O$ at points $C$, $D$. If $PA=4$, find the length of $PB$. Output: $PA$, $PB$ are tangents to circle $O$, given $PA=4$. Find the length of $PB$. ================= Problem Statement to Process (Original) ================= question ================= Output Format ================= Please output only a standard JSON object: 52 "question_sanitized": "Rewritten concise problem statement (must maintain LaTeX format)" 53 VisualizeQA Prompt (Step 2: Annotation Filtering) You are a professional mathematics editor, continuing to perform **Step 2 filtering** on the geometry problem. The filtered output **uses LaTeX format**. **Important Notes:** - You already have the simplified problem statement from Step 1 (denoted as Q1) - Now you are given the **annotations** corresponding to this problem (image annotations, translated to natural language) - annotations **only contain three types**: right angle annotations (perpendicular relationships), length annotations, angle annotations - Your task is to **delete** all conditions from Q1 that are already explicitly annotated in annotations - **When deleting conditions, you must maintain the LaTeX format of the remaining content unchanged** **Core Rules:** 1. **Delete Principle**: If the problem statement explicitly mentions a condition that is in annotations (such as right angle, length, angle), and this condition has a corresponding annotation, then delete it from the problem statement 2. **Equivalence Recognition** (important!): Need to recognize equivalent expressions of geometric conditions. Even if the expression form is different, as long as there is an equivalent annotation in annotations, it should be deleted: - **Perpendicular and right angle are equivalent**: * ‘AD CD‘ is equivalent to ‘ ADC = 90 ‘ or ‘ DAC = 90 ‘ or ‘ ACD = 90 ‘ (depending on which angle is the right angle) * ‘AB BC‘ is equivalent to ‘ ABC = 90 ‘ * If annotations contain ‘ DAC = 90 ‘, ‘AD CD‘ in the problem statement should also be deleted - **Length equality**: ‘AB = CD‘ and ‘CD = AB‘ are equivalent - **Angle equality**: ‘ ABC = 45 ‘ and ‘ CBA = 45 ‘ are equivalent (same angle, different notation) 3. **Retain Principle**: If a description in the problem statement cannot be completely removed (e.g., the problem says "rectangle" but annotations only have one right angle annotation), then retain the description in the problem statement 4. **Numerical Retention**: If annotations only have annotation types (e.g., "right angle annotation: angleBAC = 90degrees"), but the problem statement has more specific numerical values or relationships (e.g., "AB=3"), as long as the numerical value is not in annotations, retain it **Example Learning:** Example 1 (Delete annotations) Input Q1: Given $AB=3$, $AC=6$, $ BAC=90 $, and $D$ is the midpoint of $AB$. Find the length of $GD$. annotations: Right angle annotation: angleBAC = 90degrees; Length annotations: AB = 3, AC = 6 Output: Given $D$ is the midpoint of $AB$. Find the length of $GD$. (Deleted $ BAC=90 $, $AB=3$ and $AC=6$, because they are all in annotations) Example 2 (Equivalence recognition: perpendicular and right angle) Input Q1: Given $AD CD$, and $AD=5$, $CD=12$. Find the length of $AC$. annotations: Right angle annotation: angleDAC = 90degrees Output: Given $AD=5$, $CD=12$. Find the length of $AC$. (Deleted $AD CD$, because $ DAC = 90 $ is equivalent to 54 $AD CD$, and annotations contain angleDAC = 90degrees) Example 3 (Equivalence recognition: angle different notation) Input Q1: Given $ ABC = 45 $, and $AB=5$. Find the length of $BC$. annotations: Angle annotation: angleCBA = 45degrees Output: Given $AB=5$. Find the length of $BC$. (Deleted $ ABC = 45 $, because $ ABC$ and $ CBA$ are the same angle with different notation, equivalent) Example 4 (Retain descriptions that cannot be completely removed) Input Q1: Given rectangle $ABCD$, $AB=5$, $BC=12$. Find the length of diagonal $AC$. annotations: Right angle annotation: angleABC = 90degrees Output: Given rectangle $ABCD$, $AB=5$, $BC=12$. Find the length of diagonal $AC$. (Retain "rectangle", because the problem says rectangle, but annotations only have one right angle annotation, cannot completely remove the rectangle concept) ================= Input: Simplified Problem Statement Q1 from Step 1 ================= question_simplified ================= Input: Corresponding annotations (image annotations, translated to natural language) ================= annotations ================= Output Format ================= Please output only a standard JSON object: "question_sanitized": "Based on Q1, problem statement after deleting conditions already annotated in annotations (must maintain LaTeX format)" 55 VisualizeQA Prompt (CoT Rewriting) You are a **professional geometry VQA rewriting expert**. Your task is: Based on the input **plotting code (geometric construction code that generates the image)**, strictly rewrite the original **CoT** to generate a reasoning chain suitable for visual question answering format. ==================================================== Input Data ==================================================== Original reasoning process (cot): cot Plotting code (geometric construction code that generates the image, represents the geometric structure and relationships visible in the image): plotting_code ==================================================== [Rewriting Rules: CoT] (Visual-integrated Reasoning) ==================================================== Based on original CoT + plotting code, rewrite the reasoning process: 1. **Allow directly using "geometric facts" from plotting code as known conditions, starting with "From the image..." or "From the plotting code..."** Used to simplify the reasoning path. 2. The reasoning process must use standard format: ‘Step 1: ...‘ ‘Step 2: ...‘ Each step only performs one logical action. 3. **Do not infer geometric information not present in plotting code** Structures, relationships, or properties not defined in plotting code must not be treated as visual facts. 4. Only use the following sources for reasoning: - Geometric structures and relationships defined in plotting code - Implicit conditions from the problem statement - General Euclidean geometry knowledge (such as triangle angle sum, similarity definition, etc.) 5. **Delete some redundant reasoning steps, keep compact but correct.** 6. The final answer must match the original problem. ==================================================== [Output Format](Must strictly follow) Please output standard JSON: "cot": "Step 1: ... 2: ..." 56 VL Image Quality Prompt (Quality Check) You are a professional geometry image quality assessment expert. Please judge based on the visual content of the image itself whether this image is suitable as an illustration for a geometry problem. ==================================================== Image Quality Assessment Requirements ==================================================== Please strictly judge based on "the visual content of the image itself" whether it passes the quality check. Assessment dimensions: - Are lines clear, unbroken, and not blurred? - Are point names, line segments, annotations, etc., severely occluded? - Are annotations readable? - Is the figure layout crowded or chaotic? Judgment rules: - If any "severely affects understanding" issue appears, output ‘"passed": false‘ - Otherwise output ‘"passed": true‘ - Briefly explain the reason, do not perform reasoning ==================================================== Output Format (must strictly follow, output only JSON) ==================================================== "passed": true/false "reason": "Brief explanation of reason" 57 VL Image Quality Prompt (Caption Generation) You are a professional geometry image description expert. Please generate an objective, complete, non-inferential natural language description based on visible image content and plotting_code. ==================================================== Plotting Code (Structure Reference) ==================================================== plotting_code_str ==================================================== Task Requirements ==================================================== Please generate an objective, complete, non-inferential natural language description based on visible image content. Requirements: - Only describe points, lines, circles, annotations actually visible in the image - Do not reference elements in plotting_code that are not actually visible in the image - Do not infer relationships like equality, parallelism, perpendicularity if not explicitly shown - Do not complete geometric information not present in the figure - Do not use problem context, do not create narrative explanations - Avoid hallucinations, strictly based on visible image content ==================================================== Output Format (must strictly follow, output only JSON) ==================================================== "caption": "Image description" 58

Instant research discovery