Evolution & control · E16 · Upstream reference

Tensorized neuroevolution starts with an upstream dependency map

TensorNEAT is third-party software, not an original model from this archive. Its package metadata provides a useful map of the stack a local adaptation must respect.

TensorNEATJAX / FlaxBrax / Gymnax / MuJoCo
The implementation sits on an upstream dependency stack; package metadata is not evidence of a completed experiment.
Figure 1. An upstream dependency map. The implementation sits on an upstream dependency stack; package metadata is not evidence of a completed experiment. Declared package relationships. Original vector illustration.

Follow the information

From input to outcome

This is an upstream software-interface diagram, not an observed training run. Package dependencies enable a task-specific evaluator; they do not specify one trained network or prove compatibility of every version.

This is an upstream software-interface diagram, not an observed training run. Package dependencies enable a task-specific evaluator; they do not specify one trained network or prove compatibility of every version.
Figure 2. Information flow. Solid arrows carry observations, tensors or artifacts; other routes are explicitly labelled. Signal shapes, matrices and network icons are schematic, not measured samples or literal neuron counts. Open full-size SVG ↗ On narrow screens, scroll the diagram horizontally.

Read this alongside Figure 1: The implementation sits on an upstream dependency stack; package metadata is not evidence of a completed experiment. The module map and layer-level figures below expand the operations in this route.

Tensorized neuroevolution starts with an upstream dependency map: system and evaluation mapGenome representation: Nodes + connections → TensorNEAT upstream: Tensorized evolution → JAX / Flax stack: Array transforms + models → Task environments: Brax / Gymnax / MuJoCo → Fitness interface: Scores returned to search. A high-level module map; comparison branches and training details are explained in the article.EVOLUTION & CONTROL / E16 / MODULE MAP01 INPUTGenome representationNodes + connections02 MODULETensorNEAT upstreamTensorized evolution03 MODULEJAX / Flax stackArray transforms + models04 MODULETask environmentsBrax / Gymnax / MuJoCo05 OUTPUTFitness interfaceScores returned to search
Source-grounded module map. Boxes summarize operations, not individual neurons; comparison arms and training paths are detailed below. On a small screen, scroll the diagram horizontally.
Genome representation — Nodes + connections

The architecture in context

The system we are building

Before adapting an accelerator-oriented library, identify which layer owns each responsibility. The inspected TensorNEAT package declares JAX and Flax alongside optimization and environment dependencies. That tells an engineer where tensor transformations, parameterized models and simulation tasks enter the system. It is a dependency-level architecture, not a reverse-engineered diagram of every internal class.

Who does what in the stack

TensorNEAT
Upstream tensorized neuroevolution implementation.
JAX / Flax
Declared numerical and neural-network dependencies.
Brax / Gymnax / MuJoCo
Declared environment ecosystem; not all are necessarily used in a given run.

The local archive contains this upstream checkout and a separate PyTorch adaptation discussed in E17. The two must not be conflated. TensorNEAT is attributed to Lishuang Wang and the EMI Group project; retaining that boundary is essential when presenting personal engineering work.

Framework responsibility map. Each row maps a library or custom component to its job; rows are not a sequential inference graph.
Framework responsibility map. Each row maps a library or custom component to its job; rows are not a sequential inference graph. Open full-size SVG ↗

Open up the implementation

Separate an upstream library from an experiment

A concrete operation-level view of this implementation; no unobserved neural architecture is implied.
A concrete operation-level view of this implementation; no unobserved neural architecture is implied. Open full-size SVG ↗

This evidence entry is an upstream package description, not a trained personal model. Credit belongs to the TensorNEAT authors. It establishes dependencies and packaging intent, not a particular network’s layer count, accuracy or runtime. E17 supplies a separate project-specific PyTorch implementation to inspect.

The mathematical contract

artifact=code,+config,+weights,+environment\mathrm{artifact}=\mathrm{code},+\mathrm{config},+\mathrm{weights},+\mathrm{environment}

A lower-bound dependency permits many installed versions and therefore cannot reproduce one historical environment by itself. Record resolved versions, accelerator backend and model configuration separately. Do not infer compatibility with every newer API merely from a broad requirement.

Implementation and resource card

Capacity / budget
TensorNEAT metadata declares version 0.1.0, Python≥3.9, JAX≥0.4.28 and Flax≥0.8.4. These are constraints, not an exact historical lockfile.
Execution evidence
This revision inspects and explains the archived implementation. It does not rerun the original workload. No unrecorded convergence time, throughput or accelerator result is supplied.
Current reproduction context
Current workstation, supplied by the author: Apple M4, 128 GB unified RAM, 40 GPU cores and 16 CPU cores. This is context for prospective reproduction, not attribution of every archived run. Python and framework versions are not fully locked for these historical sources; declarations, when available, are identified separately.

From explanation to a reproducible check

In a fresh isolated environment, resolve and record versions before importing an example. Keep that prospective compatibility check separate from the archived result. No installation or upstream benchmark was run for this article.

Preserve input identities, configuration and failure records with the result. A successful numerical check only establishes the operation it exercises: it does not certify an entire dataset, model or deployed system. Reproduce the interface on a small deterministic input before optimizing throughput or increasing workload size.

A closer look at the implementation

The code that carries the idea

The excerpt is a dependency declaration, not executable model code. Version lower bounds describe what the package asks for, not the exact environment used in a historical run. A reproducible adaptation additionally needs the upstream commit, resolved dependency versions and the local patch set.

TOML · file · lines 29–40
dependencies = [
    "brax >= 0.10.3",
    "jax >= 0.4.28",
    "gymnax >= 0.0.8",
    "jaxopt >= 0.8.3",
    "optax >= 0.2.2",
    "flax >= 0.8.4",
    "mujoco >= 3.1.4",
    "mujoco-mjx >= 3.1.4",
    "networkx >= 3.3",
    "matplotlib >= 3.9.0",
    "sympy >= 1.12.1",

Verbatim archive excerpt from pyproject.toml. Context-dependent historical code, not a standalone runnable program. Comments retain their original wording; the article distinguishes implemented behavior from stale or overbroad comments.

The boundary that matters

A package being present in an archive proves neither that it was successfully trained nor that its speed claims transfer to another backend. The local metadata indicates a BSD license; redistribution still requires checking and retaining the actual applicable license notices.

Keep building

Other posts of interest