💬 NLP

GeoMathCode: Understanding Interleaved Math-Code Reasoning for Geometry Problem Solving

This paper introduces GeoMathCode, a framework that enhances geometry problem-solving by using programmatic code as intermediate visual outputs, revealing that supervised fine-tuning disentangles reasoning and code generation while hierarchical syntactic structures capture richer mathematical information than visual representations.

Original authors: Yingji Zhang, Yong Dai, André Freitas

Published 2026-05-26

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Yingji Zhang, Yong Dai, André Freitas

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to solve a tricky geometry puzzle, like figuring out how two curved lines interact on a graph. Usually, when a computer tries to solve this, it might just "think" in words or try to draw a picture pixel-by-pixel. But this paper introduces a new way for computers to think: GeoMathCode.

Here is the breakdown of what the researchers did, using simple analogies:

1. The Problem: Drawing with Pixels vs. Writing Instructions

Imagine you want to teach a robot to draw a perfect circle.

The Old Way (Pixel-based): You tell the robot, "Color this specific dot red, then this one, then this one..." It's like trying to paint a masterpiece by telling someone exactly which brushstroke to make at every single second. It's messy, hard to check for mistakes, and if the robot makes one tiny error, the whole picture looks wrong.
The New Way (GeoMathCode): Instead of painting dots, you give the robot a set of instructions (code). You say, "Draw a circle with a radius of 5." The robot writes a short program to do it. This is like giving a recipe instead of a painting. It's precise, easy to check (did the code run?), and if there's a mistake, you can see exactly where the recipe went wrong.

The researchers built a massive library of math problems where the "solution" isn't just a final answer, but a mix of words (explaining the logic) and code (the instructions to draw the shape).

2. The Big Discovery: Two Different "Brain Rooms"

The most interesting part of the paper is what they found inside the computer's "brain" (its internal memory space) while it was solving these problems.

They discovered that the computer has two separate "rooms" for thinking:

Room A (The Logic Room): This is where the computer figures out the math rules (e.g., "Since the curve opens downward, the values go up as we move left").
Room B (The Drawing Room): This is where the computer writes the code to actually draw the lines.

The Analogy: Imagine a chef cooking a complex meal.

In Room A, the chef is thinking, "I need to sauté the onions first, then add the spices." (The reasoning).
In Room B, the chef is physically chopping the vegetables and turning on the stove (The code).

The paper found that these two activities happen in completely different parts of the computer's brain. They don't mix up. The computer doesn't use the "drawing" part to help it "think" about the math; it uses the "thinking" part to decide what to draw, and then switches to the "drawing" part to execute the plan.

3. The "Training" Effect: Organizing the Mess

The researchers also tested what happens when they "train" the computer (a process called Supervised Fine-Tuning or SFT) using their new library of problems.

Before Training: The computer's "thinking" was a bit chaotic. It was like a library where books were thrown on the floor in a pile. It had a lot of information, but it was messy and hard to navigate.
After Training: The computer's "thinking" became like a well-organized library. The books (ideas) were still there, but now they were sorted into neat rows. The computer didn't just get "smarter" by adding more books; it got smarter by organizing the books it already had. This made its reasoning paths clearer and more structured.

4. Code is Better at "Math Symbols" Than Pictures

Finally, they compared the computer's understanding of math symbols (like $\sqrt{}$ for square root or $\pi$ for pi) when it used code versus when it used pictures.

The Finding: The computer understood the meaning of the math symbols much better when it was writing code than when it was just looking at or generating a picture.
The Analogy: It's like the difference between reading a musical score (code) and listening to a recording (picture). The score tells you exactly what the notes are and how they relate to each other. The recording just sounds nice. The computer found that the "score" (code) held the secret to the math logic much better than the "recording" (visual image).

Summary

In short, this paper says:

Stop making computers draw pictures pixel-by-pixel to solve math; let them write code instead. It's cleaner and easier to check.
Computers separate "thinking" from "drawing." They use different mental spaces for logic and for generating code.
Training organizes the brain. Teaching a computer with this method doesn't just add facts; it arranges its thinking process into a neat, efficient structure.
Code is the better translator. When it comes to understanding complex math symbols, writing code is a more powerful tool for the computer than looking at images.

Technical Summary: GeoMathCode

Problem Statement

Mathematical reasoning in Multimodal Large Language Models (MLLMs) often relies on generating multi-step solutions for geometry problems. While recent approaches like MathCanvas attempt to emulate human reasoning by incorporating auxiliary visual constructions (e.g., drawing lines or points), they typically rely on pixel-based image generation. The authors identify two primary limitations in this paradigm:

Alignment and Verification: Fine-grained cross-modal generation (text to pixel-based images) is inherently difficult to align and verify, increasing the potential for error propagation.
System Complexity: Pixel-based approaches often require additional vision-specific generators, complicating the system architecture.

The paper posits that while programmatic representations (code) are precise and verifiable, it remains unclear whether interleaved math-code reasoning fundamentally reshapes the latent geometry of multimodal reasoning or merely serves as an auxiliary output. Specifically, the authors seek to understand how reasoning trajectories evolve across layers and whether symbolic code representations capture geometric concepts differently than visual ones.

Methodology

1. Dataset Construction: GeoMathCode

The authors introduce GeoMathCode, a public multimodal dataset designed for interleaved math-code reasoning. The construction pipeline involves:

Source: Utilizing MathCanvas as the primary resource, covering eight mathematical domains (Algebra, Analytic Geometry, Calculus, etc.).
Generation: Employing Gemini 3-Flash to generate interleaved solutions containing textual reasoning, executable Python code, and corresponding visualizations.
Verification: A multi-level automated verification pipeline ensures quality:
- Rule-Based Engine (GPT-5.1): Extracts key reasoning steps ("pick-points") and mathematical rules.
- Checker (Gemini 3-Pro): Validates final answer correctness, textual reasoning logic, and code execution.
- Sandbox: Filters out samples with erroneous code execution, triggering iterative regeneration.
Scale: The final dataset comprises 10,000 training and 1,000 test samples, balanced with a 1:1 ratio of questions with and without diagrams.

2. Empirical Analysis Framework

The study evaluates representative MLLMs (Qwen3/3.5, LLaVA-Next, InternVL3.5) using both full-parameter Supervised Fine-Tuning (SFT) and LoRA. The analysis focuses on two perspectives:

Post-Training Performance: Evaluating metrics including Answer Accuracy (Ans Acc), Textual Reasoning correctness, Code Accuracy, Code Mathematical Correctness, and Text-Code Consistency.
Latent Geometry Analysis: Investigating the internal representation space of the models through:
- Trajectory Analysis: Measuring Euclidean distances between reasoning steps and code steps across transformer layers.
- Manifold Regularization: Quantifying information capacity and geometric complexity using Effective Rank (ERank) and Intrinsic Dimensionality (ID).
- Code Space Structure: Analyzing the latent representation of code syntax (control flow, function calls, data flow) using KNN and linear SVM to assess local clustering and global linear separability.
- Symbolic Probing: Comparing the ability of code embeddings versus visual embeddings to capture fine-grained mathematical symbols (e.g., $\sqrt{}$ , $\triangle$ , $\angle$ ).

Key Results

1. Performance and Disentanglement

SFT Improves Performance: Supervised Fine-Tuning significantly improves performance across all models. Qwen3.5-9B-SFT achieves the best overall results (Avg. score 0.73), outperforming baselines and LoRA variants.
Reasoning-Code Disentanglement: PCA visualizations and trajectory analysis reveal that reasoning steps and code generation steps form disentangled latent subspaces.
- The model relies primarily on textual reasoning trajectories for final answer prediction.
- Intermediate code generation acts as an auxiliary executable representation rather than an active reasoning modality that directly guides the final answer.
- This suggests a functional separation between mathematical reasoning and programmatic execution in the latent space.

2. Manifold Regularization via SFT

Structured Reasoning: SFT increases the Effective Rank (ERank) of reasoning representations (indicating richer information diversity) while simultaneously reducing the Intrinsic Dimensionality (ID) (indicating lower local geometric complexity).
Interpretation: This suggests SFT does not merely compress representations but reorganizes reasoning trajectories into more structured, canonical, and reusable computational paths, balancing information diversity with geometric regularity.

3. Hierarchical Code Space

Syntactic Subspaces: Hierarchical syntactic structures (e.g., control flow, function calls) emerge as structured latent subspaces.
Abstraction Dynamics: While high-level semantic categories remain preserved, fine-grained lexical clustering becomes mixed in deeper layers. The model reorganizes APIs into shared execution-semantic manifolds based on functional roles.
Superiority of Code over Visuals: Latent code representations capture fine-grained mathematical symbolic concepts (e.g., specific operators and geometric shapes) more effectively than visual representations, as evidenced by higher classification accuracy in probing tasks.

Significance and Claims

The paper claims to provide a new dataset and a systematic analysis of the latent geometric structure underlying interleaved math-code reasoning. The primary contributions are:

Dataset: The introduction of GeoMathCode, which facilitates the study of programmatic intermediate outputs in geometry problem solving.
Latent Geometry Insights: The demonstration that reasoning and code steps are disentangled in the latent space, challenging the notion that code generation is an active reasoning modality in the same way visual modalities might be.
SFT Effects: The finding that SFT regularizes the reasoning manifold, making it more informative yet geometrically regular, rather than simply increasing complexity.
Code vs. Visuals: The evidence that symbolic code representations are superior to visual representations for capturing fine-grained mathematical concepts.

The authors conclude that these findings motivate future research into mechanistic interpretability in LLMs, specifically regarding code execution, and the potential for pick-point-based reinforcement learning to improve reasoning reliability. They acknowledge limitations regarding the reliance on LLM-based evaluators and the relatively low final answer accuracy, suggesting future work should focus on automatic symbolic evaluation and reinforcement learning approaches (e.g., GRPO, DAPO).