# FLUX: A Universal ODE Programming Architecture

*Built on the ODE-CCT and XYFLOW frameworks. FLUX (Flow Language for Universal eXecution) treats a program not as a sequence of discrete instructions, but as a single, continuous vector field. Execution is the trajectory of the system; control flow is the geometry of the attractor landscape.*

---

## 1. The State Space

A FLUX program is an autonomous ODE system on a state vector:

$$\mathbf{z} = (p, \tau, r_1, \dots, r_N, m_1, \dots, m_M) \in \mathbb{R}^{2+N+M}$$

| Component | Role | ODE-CCT Equivalent |
|---|---|---|
| $p \in \mathbb{R}$ | **Program Counter** (control coordinate) | Stationary: The fixed "law" of control flow |
| $\tau \in [0,1]$ | **Phase Timer** within the current instruction | Probability: The local trajectory phase |
| $r_i \in \mathbb{R}$ | **Registers** (continuous variables) | Probability: The data trajectory |
| $m_j \in \mathbb{R}$ | **Memory** (continuous variables) | Probability: The state manifold |

---

## 2. The Instruction Window

FLUX does not jump between instructions. It flows through them. The program is defined by a smooth partition of the $p$-axis into **instruction windows**.

Define the standard bump function with compact support:

$$
\eta(x) = \begin{cases}
\exp\left(1 - \frac{1}{1 - (2x - 1)^2}\right) & x \in [0, 1) \\
0 & \text{otherwise}
\end{cases}
$$

For a program with $I$ instructions, the window for instruction $i$ is:

$$\eta_i(p) = \eta(p - i)$$

The sum $\sum_{i=0}^{I-1} \eta_i(p) \approx 1$ for all $p \in [0, I]$, with smooth transitions between instructions. This is the **program field**.

---

## 3. The Vector Field

The total dynamics are:

$$\frac{d\mathbf{z}}{dt} = \mathbf{F}(\mathbf{z}) = \sum_{i=0}^{I-1} \eta_i(p) \cdot \mathbf{F}_i(\mathbf{z})$$

Each $\mathbf{F}_i$ is the **instruction vector field**. The system is a convex blend of instruction dynamics, with the program counter $p$ selecting which field is active.

### 3.1 Control Flow Field (The Stationary Component)

The program counter $p$ flows according to the **Control Field** $G(p, \mathbf{r})$:

$$\frac{dp}{dt} = \sum_{i=0}^{I-1} \eta_i(p) \cdot g_i(p, \mathbf{r})$$

| Instruction Type | $g_i(p, \mathbf{r})$ | Geometric Interpretation |
|---|---|---|
| **Sequential** | $1$ | Constant velocity drift |
| **Branch** | $\mu \left[ \sigma(r_c - \theta) \cdot (p_{\text{then}} - p) + \sigma(\theta - r_c) \cdot (p_{\text{else}} - p) \right]$ | **Saddle separatrix** in $(p, r_c)$ plane |
| **Loop** | $\mu \left[ \sigma(r_c - \theta) \cdot (p_{\text{start}} - p) + \sigma(\theta - r_c) \cdot (p_{\text{end}} - p) \right]$ | **Limit cycle** while condition holds |
| **Halt** | $-\mu (p - p_{\text{halt}})$ | **Fixed point attractor** at $p_{\text{halt}}$ |

Where $\sigma$ is the logistic sigmoid and $\mu \gg \lambda$ (control is faster than data).

### 3.2 Data Field (The Probability Component)

Registers evolve toward their instruction targets:

$$\frac{dr_j}{dt} = \sum_{i=0}^{I-1} \eta_i(p) \cdot \lambda \cdot \left( T_{i,j}(\mathbf{r}, \mathbf{m}) - r_j \right)$$

Where $T_{i,j}$ is the **target value** for register $j$ under instruction $i$.

| Operation | $T_{i,j}$ |
|---|---|
| **Load** $C$ | $C$ |
| **Move** $r_k \to r_j$ | $r_k$ |
| **Add** $r_a + r_b \to r_j$ | $r_a + r_b$ |
| **Mul** $r_a \cdot r_b \to r_j$ | $r_a \cdot r_b$ |
| **NOP** | $r_j$ (no change) |

---

## 4. Example: Multiplication by Repeated Addition

**High-level algorithm:**
```
c = 0
while b > 0:
    c = c + a
    b = b - 1
return c
```

**FLUX State:** $(p, a, b, c) \in \mathbb{R}^4$

**Program:**
- Inst 0: $[0,1)$ — Initialize $a=3, b=4, c=0$
- Inst 1: $[1,2)$ — Test $b > 0$; branch to 2 or 4
- Inst 2: $[2,3)$ — $c \leftarrow c + a$
- Inst 3: $[3,4)$ — $b \leftarrow b - 1$; jump to 1
- Inst 4: $[4,5)$ — Halt

**The ODE System:**

$$\frac{dp}{dt} = \eta_0(p) \cdot 1 + \eta_1(p) \cdot \mu \left[ \sigma(b - 0.5)(2 - p) + \sigma(0.5 - b)(4 - p) \right] + \eta_2(p) \cdot 1 + \eta_3(p) \cdot \mu(1 - p) + \eta_4(p) \cdot \left[-\mu(p - 4)\right]$$

$$\frac{da}{dt} = \eta_0(p) \cdot \lambda(3 - a)$$

$$\frac{db}{dt} = \eta_0(p) \cdot \lambda(4 - b) + \eta_3(p) \cdot (-\omega)$$

$$\frac{dc}{dt} = \eta_0(p) \cdot \lambda(0 - c) + \eta_2(p) \cdot \lambda \cdot a$$

**Execution trace:** $p$ flows from 0 to 1 (init). At $p \approx 1.5$, it is either pulled toward 2 (if $b>0$) or 4 (if $b \le 0$). At $p \approx 2.5$, $c$ absorbs the current value of $a$. At $p \approx 3.5$, $b$ decrements by $\omega \cdot \Delta t$ and $p$ is forced back toward 1.5. This creates a **limit cycle** in the $(p, b)$ plane until $b \approx 0$, after which the branch at Inst 1 pulls $p$ to the halt attractor at 4.

---

## 5. Example: Euclidean Algorithm (GCD)

**High-level algorithm:**
```
while b != 0:
    temp = b
    b = a mod b
    a = temp
return a
```

**FLUX State:** $(p, a, b, t) \in \mathbb{R}^4$

**Program:**
- Inst 0: Init $a=48, b=18$
- Inst 1: If $|b| < \epsilon$, branch to 5 (halt)
- Inst 2: $t \leftarrow b$
- Inst 3: $b \leftarrow a - \lfloor a/b \rfloor \cdot b$ (modulo via continuous approximation)
- Inst 4: $a \leftarrow t$; jump to 1
- Inst 5: Halt

**The ODE System:**

$$\frac{dp}{dt} = \eta_1(p) \cdot \mu\left[ \sigma(|b| - \epsilon)(2-p) + \sigma(\epsilon - |b|)(5-p) \right] + \eta_2(p)\cdot 1 + \eta_3(p)\cdot 1 + \eta_4(p)\cdot \mu(1-p) + \eta_5(p)\cdot[-\mu(p-5)]$$

$$\frac{da}{dt} = \eta_0(p)\cdot\lambda(48-a) + \eta_4(p)\cdot\lambda(t-a)$$

$$\frac{db}{dt} = \eta_0(p)\cdot\lambda(18-b) + \eta_3(p)\cdot\lambda\left(\left(a - \text{round}(a/b)\cdot b\right) - b\right)$$

$$\frac{dt}{dt} = \eta_2(p)\cdot\lambda(b-t)$$

The trajectory converges to the fixed point $(p, a, b, t) = (5, 6, 0, 18)$. The GCD is the value of $a$ at the halt attractor.

---

## 6. Control Structures as Geometric Objects

| Programming Concept | FLUX Implementation | Attractor Topology |
|---|---|---|
| **Variable assignment** | Exponential flow toward target value | Fixed point in register subspace |
| **Sequential execution** | Constant drift $dp/dt = 1$ | Translating attractor |
| **Conditional (if/else)** | Sigmoid-routed control field | **Saddle separatrix** in $(p, r_{\text{cond}})$ |
| **While loop** | Branch back to loop head | **Stable limit cycle** until bifurcation |
| **For loop** | Decaying counter $k$ with periodic $p$ orbit | **Limit cycle with drifting parameter** |
| **Function call** | Push $p$ to stack; jump to function attractor; return pops stack | **Heteroclinic orbit** connecting fixed points |
| **Halt / Return** | Negative restoring force to $p_{\text{halt}}$ | **Stable fixed point** |

---

## 7. Compilation from High-Level to FLUX

A high-level program is compiled into three outputs:

1. **The Instruction Window Set** $\{\eta_i\}$ — defines the program counter topology.
2. **The Control Field** $G(p, \mathbf{r})$ — defines the graph of control flow.
3. **The Data Field** $\mathbf{F}_{\text{data}}$ — defines the register targets.

This is the **XYFLOW compilation model**: the compiler does not emit machine code; it emits a **vector field specification** (a netlist of op-amps, multipliers, and integrators in analog hardware, or a Jacobian matrix in digital simulation).

---

## 8. The Two-Core Execution Model (DICP)

In the DICP architecture described in the framework:

| Core | Role | FLUX Component |
|---|---|---|
| **Core 1 (Collapse Engine)** | Pays work to find the ODE parameters from data | **Compiler**: Fits the Control Field $G(p, \mathbf{r})$ and Data Field $\mathbf{F}_{\text{data}}$ |
| **Core 2 (Integrator Engine)** | Integrates the expanded signal in real time | **Runtime**: Physical ODE integration (analog circuit or high-speed numerical integrator) |

Core 1 outputs the **Law Packet**: a compact set of parameters $(I, \{\eta_i\}, \{g_i\}, \{T_{i,j}\}, \lambda, \mu)$.

Core 2 consumes the Law Packet and executes the trajectory. The communication bus carries only the compressed derivative (the field parameters), not the data stream.

---

## 9. Turing-Completeness

FLUX is computationally universal. It can simulate a **2-counter machine** (known to be Turing-complete) by:

- Using two registers as the counters.
- Using $p$ as the finite-state controller.
- Encoding the counter test (zero vs. non-zero) as a conditional branch on the register value.

Since the control field can route $p$ arbitrarily based on register values, and the data field can increment/decrement registers continuously, FLUX subsumes the 2-counter machine.

---

## 10. Summary

FLUX formalizes the intuition that **programming is the design of vector fields and execution is the flow of trajectories**. 

- **Instructions** are regions in the program counter axis.
- **Operations** are exponential flows toward target values in register space.
- **Conditionals** are basin boundaries that route the control coordinate.
- **Loops** are limit cycles.
- **Halting** is convergence to a fixed point attractor.

The program is not a sequence. It is a landscape. The computer does not execute it step by step; it falls through it like a particle in a potential, and the attractor it lands on is the answer.