---
title: 'BehaveSim: Behavior-Based Algorithm Similarity'
url: https://www.emergentmind.com/topics/behavesim
type: topic
---

# BehaveSim: Behavior-Based Algorithm Similarity

Searching arXiv for the cited BehaveSim paper and closely related recent work to ground the article.
BehaveSim is a behavior-based similarity metric for algorithms introduced in the context of Large Language Model-based Automated Algorithm Design (LLM-AAD). It is designed to measure **algorithmic similarity** through execution behavior rather than through source-code form or final outputs, by comparing sequences of intermediate solutions produced during problem solving, termed **problem-solving trajectories** (PSTrajs). The method was proposed to address a recurring ambiguity in AI-generated code: programs may appear similar syntactically while embodying different algorithmic logic, or may differ syntactically while implementing the same underlying strategy [2603.02787].

## 1. Concept and problem setting

BehaveSim was introduced in “Rethinking Code Similarity for Automated Algorithm Design with LLMs” [2603.02787] as a response to a specific limitation in LLM-AAD. In this setting, the main design principle behind an algorithm is often embedded implicitly in generated code rather than stated separately. As a result, evaluating novelty or diversity by syntax-oriented code metrics can be misleading.

The paper distinguishes three notions of similarity. **Syntactic similarity** concerns resemblance in source form. **Output equivalence** or result similarity concerns whether programs produce the same final answers. **Algorithmic similarity**, which BehaveSim targets, concerns whether two programs embody the same underlying problem-solving logic [2603.02787]. The motivating examples are concrete. Breadth-first search and depth-first search can look similar to token-, AST-, graph-, or embedding-based metrics when their code structures overlap, despite being behaviorally distinct. Conversely, recursive and iterative implementations of depth-first search can look dissimilar syntactically while remaining algorithmically equivalent. Output-based comparison fails in another way: insertion sort and bubble sort always produce the same sorted array, so output equivalence conflates different algorithms [2603.02787].

This framing places BehaveSim within a broader shift toward behavior-centered analysis seen in several adjacent literatures. In animal and multi-agent simulation, trajectory-level comparison has been used to align simulated and observed behavior rather than relying only on end states, as in the ant-colony environment of “A Simulation Environment for the Neuroevolution of Ant Colony Dynamics” [2406.13147] and the DTW-shaped imitation objectives of AnimaRL in “Data-driven simulator of multi-animal behavior with unknown dynamics via offline and online reinforcement learning” [2510.10451]. A plausible implication is that BehaveSim transfers a similar trajectory-centric logic from embodied systems to algorithms, replacing movement trajectories with sequences of intermediate solutions.

## 2. Problem-solving trajectories

The central object in BehaveSim is the **problem-solving trajectory**, abbreviated PSTraj. The method is defined for iterative algorithms that progressively refine candidate solutions. The paper writes this scope as a mapping
\[
f: \mathbf{x}\rightarrow\mathbf{x}
\]
with iterative update
\[
x_{t+1} = f(x_{t}),
\]
where \(x_t\) is the solution at iteration \(t\) [2603.02787].

For an algorithm on a given problem instance, BehaveSim records the sequence
\[
\mathcal{T} = (x_0, x_1, \dots, x_T),
\]
where \(x_0\) is the initial solution and \(x_T\) is the final one [2603.02787]. The paper emphasizes that these are not low-level execution traces of all variables. Instead, each \(x_t\) is a **task-defined intermediate solution** that is semantically meaningful for the problem at hand. Examples given in the paper include a complete but suboptimal vector in convex optimization, the visited-node subset or order in binary-tree traversal, a partially constructed tour in TSP, and the current set in ASP [2603.02787].

This design choice is foundational. Generic execution traces are treated as too noisy to reflect algorithmic logic directly, whereas PSTrajs are intended to isolate the evolving solution structure that reveals how an algorithm works. The paper states that BehaveSim therefore requires **task-specific hooks** at the algorithm–problem interface. For example, in TSP one records the route after each city selection; in ASP one records the currently built admissible set after each insertion [2603.02787]. This makes BehaveSim more semantically targeted than language-level tracing baselines built with tools such as `pysnooper`.

The emphasis on intermediate states makes BehaveSim especially suitable for constructive heuristics, iterative optimization, search, sorting, traversal, and training-like procedures [2603.02787]. The paper notes that this scope is both a strength and a limitation: the method assumes that semantically meaningful intermediate solutions are observable and extractable.

## 3. Metric definition and computation

BehaveSim compares algorithms in two stages: first by comparing intermediate states, then by aligning full trajectories. The distance between two states depends on the solution type. For categorical, ordinal, and permutation solutions, the paper uses normalized edit distance. Although the displayed equation is corrupted in the provided text, the intended form is stated clearly as
\[
d(x,y) = \frac{d_{\mathrm{edit}(x,y)}}{d_{\max}}.
\]
For discrete and continuous solutions, it uses normalized Euclidean distance:
\[
d_{\mathrm{euc}(x,y) = \|x-y\|_2,
\]
\[
d(x,y) = \|x-y\|_2/D
\]
with \(D\) a problem-specific upper bound [2603.02787].

Given two trajectories \(X = (x_1, \dots, x_m)\) and \(Y = (y_1, \dots, y_n)\), BehaveSim aligns them using dynamic time warping:
\[
DTW(X,Y) = \min_{\pi \in \mathcal{A}(m,n)} \sum_{(i,j) \in \pi} d(x_i, y_j),
\]
where \(\mathcal{A}(m,n)\) is the set of alignment paths [2603.02787]. DTW is chosen because it handles trajectory-length differences and temporal misalignment naturally. The paper reports that mean pairwise distance, DTW, and ERP are highly correlated in an appendix comparison, while cosine behaves differently; DTW is retained because varying lengths and temporal shifts are central to the target use case [2603.02787].

The pairwise trajectory similarity is then
\[
\text{Sim}_{\text{PSTraj}(X, Y) = 1 - \frac{DTW(X, Y)}{\min\{|X|,|Y|\}}.
\]
Again, the source text is slightly malformed, but the intended normalization by the shorter trajectory length is explicit [2603.02787].

The full BehaveSim score averages PSTraj similarity across both problem instances and starting points:
\[
\text{BehaveSim}(A_1, A_2) := \mathbb{E}_{I \sim P^I} \left[ \mathbb{E}_{s \sim S_I} \left[ \text{Sim}_\text{PSTraj}\left( \mathcal{T}(A_1, I, s), \mathcal{T}(A_2, I, s) \right) \right] \right].
\]
This nested expectation is important because algorithmic similarity is not defined on a single run alone; it is defined over a distribution of instances and, when relevant, starting states [2603.02787].

The computational pipeline is therefore: execute the candidate algorithms on selected instances and starts; collect PSTrajs; compute normalized distances between intermediate states; align trajectories with DTW; convert the resulting distance into PSTraj similarity; and average across runs to obtain BehaveSim [2603.02787]. The paper also describes two efficiency approximations, **trajectory truncation** and **trajectory sampling**, and reports robustness under moderate truncation and sampling rates. A straightforward DTW implementation has \(O(mn)\) time and memory, so these approximations serve as practical cost controls [2603.02787].

## 4. Empirical behavior relative to prior similarity measures

The principal empirical claim of BehaveSim is that it matches algorithmic similarity better than source-based or output-based baselines. The paper evaluates four curated pair types:

- **Type-1**: similar text, similar results, different behavior  
- **Type-2**: similar text, different results, different behavior  
- **Type-3**: dissimilar text, similar results, similar behavior  
- **Type-4**: dissimilar text, similar results, different behavior [2603.02787]

BehaveSim yields the following similarities:

| Pair type | BehaveSim |
|---|---:|
| Type-1 | 0.56 |
| Type-2 | 0.73 |
| Type-3 | 1.00 |
| Type-4 | 0.46 |

These values are contrasted in the paper with static code metrics and output equivalence. CodeBLEU gives \(0.97/0.94/0.91/0.75\) on Types 1–4, Jina code embeddings give \(0.99/0.99/0.90/0.84\), and AST gives \(0.96/1.00/0.76/0.57\). Output equivalence gives \(1.00/0.00/1.00/1.00\), which fails to distinguish Type-4 from true behavioral equivalence [2603.02787]. BehaveSim is reported as the only method among those compared that perfectly identifies Type-3 as behaviorally identical while reducing similarity on the behaviorally different types.

The paper also evaluates execution-trace baselines derived from `pysnooper` traces combined with BLEU or embedding models. These still remain high on Type-1 and Type-2; for example, Exe-Trace+Jina-Code-Emb gives \(1.00/1.00/0.87/0.77\) [2603.02787]. The authors interpret this as evidence that merely “using execution information” is insufficient if the representation does not isolate problem-solving structure.

Several individual cases reinforce the point. Recursive versus iterative BFS, bubble sort, insertion sort, merge sort, first fit, and best fit all receive BehaveSim \(= 1.00\), while static code metrics vary substantially [2603.02787]. This is presented as evidence that BehaveSim detects behavioral equivalence even when syntax changes.

## 5. Use in automated algorithm design

BehaveSim was introduced not only as an analysis metric but as an active component in LLM-AAD systems. The paper integrates it into **FunSearch** and **EoH** in distinct ways [2603.02787].

In **FunSearch+BehaveSim**, the original multi-island database is reorganized so that islands reflect **behavioral similarity** rather than inheritance lineage. Initialization samples \(N_{\text{init}=100\) random algorithms, clusters them by BehaveSim, and assigns them to \(N_{\text{isl}\) islands [2603.02787]. During search, few-shot examples can be selected inter-island or intra-island, with probability \(p_{\text{s1}\) controlling inter-island selection. After evaluation, a newly generated algorithm is assigned to the island whose members are behaviorally most similar:
\[
\text{target\_island} = \argmax_{i \in [1, N_\text{isl}]} \left( \frac{1}{|I_i|} \sum_{t_j^i \in I_i} \mathrm{BehaveSim}(t, t_j^i) \right).
\]
This makes BehaveSim the organizing mechanism for diversity management, exploration, and exploitation [2603.02787].

In **EoH+BehaveSim**, BehaveSim enters as a helper objective through behavioral dissimilarity relative to the current population. The paper states that “smaller is better,” meaning the system uses dissimilarity rather than raw similarity in the multi-objective machinery. It computes
\[
\boldsymbol{S}[i,j] \leftarrow -\text{BehaveSim}(\boldsymbol{P}[i], \boldsymbol{P}[j]),
\]
combines this with a dominance matrix \(\boldsymbol{D}\), and uses the resulting scores for parent selection and survival [2603.02787]. In this formulation, BehaveSim affects population maintenance directly.

The benchmarks are three algorithm-design tasks: **Admissible Set Problem (ASP)**, **Traveling Salesman Problem (TSP)**, and **Circle Packing Problem (CPP)**, with budgets of 10,000 evaluations for ASP and 2,000 for TSP and CPP, a 50-second timeout per candidate, and GPT-5-Nano as the generator [2603.02787].

For **top-1** performance, the paper reports:

| Task | Baseline | + BehaveSim |
|---|---:|---:|
| ASP, FunSearch | 5.84 | 5.24 |
| ASP, EoH | 5.99 | 5.33 |
| TSP, FunSearch | 25.22 | 17.37 |
| TSP, EoH | 18.86 | 16.55 |
| CPP, FunSearch | 2.6259 | 2.6293 |
| CPP, EoH | 2.5724 | 2.6263 |

For **top-10** performance, it reports:

| Task | Baseline | + BehaveSim |
|---|---:|---:|
| ASP, FunSearch | 6.15 | 5.28 |
| ASP, EoH | 6.08 | 5.59 |
| TSP, FunSearch | 27.46 | 18.05 |
| TSP, EoH | 19.68 | 17.20 |
| CPP, FunSearch | 2.6127 | 2.6249 |
| CPP, EoH | 2.5535 | 2.6234 |

These are means over three runs, with standard deviations reported in the paper [2603.02787]. The largest gains occur on TSP, which the paper interprets as suggesting that behavioral diversity is especially useful in constructive heuristic search.

The paper also analyzes island structure in FunSearch-style search. It reports that BehaveSim produces lower intra-island distances and higher inter-island distances than vanilla FunSearch, using average dissimilarities based on \(1-\text{BehaveSim}\) [2603.02787]. An ablation on ASP shows that increasing inter-island selection probability \(p_{\text{s1}\) from 0 to 0.5 improves performance, and removing clustering during initialization degrades performance significantly. This suggests that both cross-island mixing and behavior-based clustering contribute to gains.

## 6. Algorithm analysis, assumptions, and limitations

A second major use case is **algorithm analysis**. The paper samples 30 algorithms from a FunSearch+BehaveSim TSP run and clusters them using hierarchical clustering with BehaveSim and with CodeBLEU [2603.02787]. The resulting dendrograms differ meaningfully. BehaveSim groups algorithms by constructive strategy rather than implementation form. One highlighted example is Code 6 and Code 8, which are structurally different but effectively behave like nearest-neighbor selection because of a bug or weighting choice; BehaveSim clusters them together. Conversely, Code 11 and Code 12 are structurally similar according to CodeBLEU but diverge behaviorally because of differences in final scoring logic; BehaveSim separates them [2603.02787].

This analytical use connects BehaveSim to a broader family of simulation-oriented representations in which the object of study is not only outcome but trajectory. Similar trajectory-centric reasoning appears in data-driven animal simulation systems such as AnimaRL, where dynamic time warping is used to compare trajectories between cyber and physical spaces [2510.10451]. This suggests that BehaveSim belongs to a wider methodological pattern: state evolution is treated as the relevant object for similarity and intervention, rather than static descriptions alone.

The method also has clear assumptions and limits. It is best suited to algorithms that generate semantically meaningful intermediate solutions over time [2603.02787]. It requires executable code and task-specific PSTraj instrumentation. The paper notes that stochastic algorithms can be handled either by fixing the random seed or by estimating distributions over next states and replacing pointwise state distance with a divergence \(D(P_{t+1}(x),P_{t+1}(y))\), though the latter is more expensive [2603.02787].

Another limitation is representation dependence. If the chosen intermediate state omits crucial aspects of logic, then behaviorally distinct algorithms may appear similar, or equivalent algorithms may appear different. The paper also emphasizes that BehaveSim measures **behavioral similarity only**; it does not capture asymptotic complexity, memory usage, or proof-level novelty [2603.02787]. This corrects a possible misconception that BehaveSim is a universal notion of algorithmic equivalence. It is narrower: it measures similarity in the way solutions are constructed over time.

Implementation and reproducibility are comparatively strong. The paper states that code and data are open-sourced at `https://github.com/RayZhhh/behavesim`, and it reports concrete search settings such as 10 islands for FunSearch, population size 20 for EoH, identical template algorithms for fairness, and 50-second timeout per candidate [2603.02787]. Reproducing BehaveSim nevertheless requires reconstructing the exact PSTraj hooks for each task, since those hooks are task-specific by design.

## 7. Place within behavior-centered simulation research

Although BehaveSim concerns algorithms rather than embodied agents, it belongs to a broader turn toward **behavior-centered simulation and comparison**. In biological and social behavior simulators, state trajectories have increasingly been treated as primary objects of analysis. The ant-colony environment of “A Simulation Environment for the Neuroevolution of Ant Colony Dynamics” focuses on reproducing target ant trails from locally available sensory information [2406.13147]. AnimaRL uses a distance-based pseudo-reward built on dynamic time warping to align simulated and observed trajectories for flies, newts, silkmoths, and synthetic agents [2510.10451]. These systems differ sharply in domain, but they share with BehaveSim the premise that trajectory structure reveals mechanism more reliably than static endpoints.

A plausible implication is that BehaveSim generalizes this principle to algorithm design: code is treated analogously to an agent, intermediate solutions to a behavioral trace, and DTW-based alignment to a measure of behavioral equivalence. In that sense, BehaveSim does not simulate embodied behavior; it simulates and compares **problem-solving behavior**. Its importance lies in making that behavior measurable enough to guide search, clustering, and analysis in an ecosystem increasingly populated by AI-generated algorithms [2603.02787].

BehaveSim is therefore best understood as a metric and analytic framework rather than as a conventional simulator. Its core claim is concise: to compare algorithms, compare not what their code looks like and not only what outputs they return, but how they reach those outputs through sequences of intermediate solutions [2603.02787].

Source: https://www.emergentmind.com/topics/behavesim