Hopfield networks (spec-level) #
This file gives a Hopfield network model as a set of explicit mathematical definitions.
- A state is a Boolean vector
Fin n → Bool(activationtrue ↦ +1,false ↦ -1). - Parameters are a weight matrix
W : Fin n → Fin n → αand thresholdsθ : Fin n → α. - An asynchronous update picks a neuron
uand updates only that coordinate.
Intended use: mathematical scalars (ℚ, ℝ, etc.) and theorem statements/proofs.
For computation, instantiate α := ℚ (or Rat) and evaluate seqStates / energy via #eval
in an example file.
Note: we also provide Tensor-shaped wrappers (StateT, ParamsT) so users can work with
Tensor _ (.dim n .scalar) instead of raw Fin n → _.
References #
- Hopfield (1982), "Neural networks and physical systems with emergent collective computational abilities": https://www.pnas.org/doi/10.1073/pnas.79.8.2554 ("Neurons with graded response have collective computational properties " ++ "like those of two-state neurons"): https://www.pnas.org/doi/10.1073/pnas.81.10.3088
- Ramsauer et al. (2020), "Hopfield Networks is All You Need": https://arxiv.org/abs/2008.02217
Relationship to the Hopfield formalization case study #
This file provides the definitions (update rule, energy, trajectories). The global-dynamics
results (energy monotonicity, fixed-point convergence bounds, tie-handling lemmas, etc.) are proved
in NN/MLTheory/Proofs/Hopfield/* against these definitions.
If you’re reading this alongside “Formalized Hopfield Networks and Boltzmann Machines” (2025), the correspondence is:
updateAt/seqStatesformalize the asynchronous update dynamics,energyis the Lyapunov/energy functional used for convergence arguments,- theorems in
NN.MLTheory.Proofs.Hopfield.EnergyandNN.MLTheory.Proofs.Hopfield.Convergencecapture the classic “energy decreases ⇒ convergence” theorem pattern for finite state spaces.
Core data #
Hopfield state as a Boolean activation vector.
Instances For
Hopfield state as a vector tensor Tensor Bool (.dim n .scalar).
This is a convenience wrapper so Hopfield models can interoperate with the rest of TorchLean's tensor-shaped spec APIs.
Instances For
Convert a tensor state to the underlying function representation.
Instances For
Convert a function state to a tensor state.
Instances For
Matrix-vector product (as a function, not an array-backed matrix).
Instances For
Hopfield parameters as tensor-shaped weights and thresholds.
- W : Tensor α (Shape.dim n (Shape.dim n Shape.scalar))
W.
- θ : Tensor α (Shape.dim n Shape.scalar)
Instances For
Hopfield update dynamics #
Asynchronous update at a single coordinate u.
We implement the standard thresholded sign rule:
s[u] := (θ_u ≤ net_u)
Interpreting true ↦ +1 and false ↦ -1, this corresponds to:
x_u := +1 if net_u ≥ θ_u, otherwise x_u := -1.
Tie-handling (net_u = θ_u) matters for formal convergence arguments; we pick the convention
"ties go to +1" via ≤.
Instances For
A state is stable (a fixed point) if updating any single coordinate does nothing.
Instances For
Count how many units are in the true (+1) state.
Instances For
Hopfield energy #
The classical Hopfield energy for a state s (quadratic term + linear threshold term).
With x = actVec s the ±1 encoding, the energy is:
E(s) = -1/2 * Σ_i Σ_j W_ij x_i x_j + Σ_i θ_i x_i.
When W is symmetric and has a zero diagonal, asynchronous updates are known to monotonically
decrease (or not increase) E, which is the classic Lyapunov-style argument for convergence.
Instances For
State sequence induced by an asynchronous update schedule useq.
useq : Nat → Fin n picks which coordinate to update at each discrete time step.
PyTorch analogy: there is no direct equivalent in typical NN libraries, but you can think of it as an explicit, deterministic "update schedule" for coordinate descent.
Instances For
Executable Hopfield (backend-friendly) #
The definitions above (net, energy, …) are written in a math-first style using ∑ over Fin n.
That is the right presentation for proofs, but it bakes in algebraic typeclasses like
AddCommMonoid and uses Finset sums.
When we execute Hopfield over IEEE-like scalars (e.g. Float, IEEE32Exec), we do not want to
pretend those algebraic laws hold exactly: NaNs and rounding make addition non-associative and
non-commutative in general. So for runtime execution we provide a “plain loop” variant that:
- requires only the operations from
[Context α], - uses explicit
List.foldliteration overFin n.
This is the same model, just written in a way that stays honest about runtime arithmetic.
References:
- IEEE 754-2019 (why NaNs/rounding break algebraic laws): https://doi.org/10.1109/IEEESTD.2019.8766229
- Goldberg (1991), classic floating-point background: https://doi.org/10.1145/103162.103163
Net input to unit u computed by explicit iteration.
This matches Hopfield.netT, but avoids Finset sums so it can execute over IEEE-like scalars.
Instances For
Asynchronous update of a single coordinate u, using the same “ties go to +1” convention as the
spec definition (θ_u ≤ net_u).