Papers
Topics
Authors
Recent
Search
2000 character limit reached

BehaveSim: Behavior-Based Algorithm Similarity

Updated 5 July 2026
  • BehaveSim is a behavior-based similarity metric that evaluates algorithms by comparing problem-solving trajectories rather than source code or outputs.
  • It uses dynamic time warping to align iteratively generated intermediate solutions, enabling accurate measurement of behavioral similarity.
  • In automated algorithm design, BehaveSim clusters and diversifies candidate algorithms by quantifying subtle differences in their problem-solving behaviors.

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 LLM-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 (Zhang et al., 3 Mar 2026).

1. Concept and problem setting

BehaveSim was introduced in “Rethinking Code Similarity for Automated Algorithm Design with LLMs” (Zhang et al., 3 Mar 2026) 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 (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026).

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” (Crosscombe et al., 2024) 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” (Fujii et al., 12 Oct 2025). 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:xxf: \mathbf{x}\rightarrow\mathbf{x}

with iterative update

xt+1=f(xt),x_{t+1} = f(x_{t}),

where xtx_t is the solution at iteration tt (Zhang et al., 3 Mar 2026).

For an algorithm on a given problem instance, BehaveSim records the sequence

T=(x0,x1,,xT),\mathcal{T} = (x_0, x_1, \dots, x_T),

where x0x_0 is the initial solution and xTx_T is the final one (Zhang et al., 3 Mar 2026). The paper emphasizes that these are not low-level execution traces of all variables. Instead, each xtx_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 (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026). 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)=dedit(x,y)dmax.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,$

xt+1=f(xt),x_{t+1} = f(x_{t}),0

with xt+1=f(xt),x_{t+1} = f(x_{t}),1 a problem-specific upper bound (Zhang et al., 3 Mar 2026).

Given two trajectories xt+1=f(xt),x_{t+1} = f(x_{t}),2 and xt+1=f(xt),x_{t+1} = f(x_{t}),3, BehaveSim aligns them using dynamic time warping: xt+1=f(xt),x_{t+1} = f(x_{t}),4 where xt+1=f(xt),x_{t+1} = f(x_{t}),5 is the set of alignment paths (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026).

The pairwise trajectory similarity is then

xt+1=f(xt),x_{t+1} = f(x_{t}),6

Again, the source text is slightly malformed, but the intended normalization by the shorter trajectory length is explicit (Zhang et al., 3 Mar 2026).

The full BehaveSim score averages PSTraj similarity across both problem instances and starting points: xt+1=f(xt),x_{t+1} = f(x_{t}),7 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 (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026). 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 xt+1=f(xt),x_{t+1} = f(x_{t}),8 time and memory, so these approximations serve as practical cost controls (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026)

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 xt+1=f(xt),x_{t+1} = f(x_{t}),9 on Types 1–4, Jina code embeddings give xtx_t0, and AST gives xtx_t1. Output equivalence gives xtx_t2, which fails to distinguish Type-4 from true behavioral equivalence (Zhang et al., 3 Mar 2026). 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 xtx_t3 (Zhang et al., 3 Mar 2026). 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 xtx_t4, while static code metrics vary substantially (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026).

In FunSearch+BehaveSim, the original multi-island database is reorganized so that islands reflect behavioral similarity rather than inheritance lineage. Initialization samples xtx_t5 random algorithms, clusters them by BehaveSim, and assigns them to xtx_t6 islands (Zhang et al., 3 Mar 2026). During search, few-shot examples can be selected inter-island or intra-island, with probability xtx_t7 controlling inter-island selection. After evaluation, a newly generated algorithm is assigned to the island whose members are behaviorally most similar: xtx_t8 This makes BehaveSim the organizing mechanism for diversity management, exploration, and exploitation (Zhang et al., 3 Mar 2026).

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

xtx_t9

combines this with a dominance matrix tt0, and uses the resulting scores for parent selection and survival (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026). 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 tt1 (Zhang et al., 3 Mar 2026). An ablation on ASP shows that increasing inter-island selection probability tt2 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 (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026).

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 (Fujii et al., 12 Oct 2025). 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 (Zhang et al., 3 Mar 2026). 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 tt3, though the latter is more expensive (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026). 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 (Zhang et al., 3 Mar 2026). 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 (Crosscombe et al., 2024). 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 (Fujii et al., 12 Oct 2025). 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 (Zhang et al., 3 Mar 2026).

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 (Zhang et al., 3 Mar 2026).

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to BehaveSim.