◄ WORLD V · SONNY 5DART 392 · a helldive at the net

THE CONVOLUTION equivariance built into the wiring — the same kernel everywhere, so a shift shifts the output

A convolution slides one small kernel across the whole input, applying the same weights at every position. That weight-sharing is not an accident of tuning — it is the mechanism that enacts translation-equivariance: because the kernel is identical everywhere, shifting the input shifts the output exactly, conv(shift·x) = shift·conv(x). A correct-but-different filter with per-position weights would be just as expressive and lack the property entirely. This is the load-bearing case for the batch: equivariance here is caused by the construction (tie the weights and it holds; untie them and it dies), which is why convolutional networks learn features that work anywhere in an image.

THE TECHNIQUE shared kernel ⇒ conv(shift·x) = shift·conv(x) (translation-equivariant)

The demo convolves a signal with a kernel, then shifts the input — the output shifts identically (shift-equivariant): live demo







  
HISTORY & CREDIT LeCun 1989 · weight-sharing

  
“A CNN's power is depth.” — its foundation is weight-sharing, which enacts translation-equivariance: the same kernel everywhere means a feature found here is found anywhere. cited

  
the mechanism · one kernel, applied identically at every position (weight-sharing).
enacts · conv(shift·x)=shift·conv(x) — equivariance by construction, not by the task.
1980 · Kunihiko Fukushima — the Neocognitron originated the convolutional architecture (local receptive fields + weight-sharing/shift-invariance), pre-backprop; 1989 · Yann LeCun — trained one by backpropagation (LeNet). The classical convolution is centuries older (signal processing, the impulse response).

  
One kernel everywhere, so a shifted input gives a shifted output — equivariance welded into the wiring. Untie the weights and it is gone. convolution






  
RECOMMEND FOR I-13 shift-equivariance, on the compiler

  
On the canonical compiler, convolving [1,2,3,4] with kernel [1,1] gives [3,5,7]; shift the input and the output shifts identically (shift_equivariant=1):

  
$ i13 run sy_convolution.i13   # y[i]=x[i]+x[i+1]; shift-equivariance
RUN OK · 245 step(s) · peak stack 6 · call depth 4
y0 = 3                     -- conv([1,2,3,4],[1,1]) = [3,5,7]
shift_equivariant = 1      -- shift the input -> the output shifts identically

  
Recommend — the keeper shot's load-bearing case. Convolution is equivariance caused by a mechanism choice: the shared kernel makes conv(shift·x)=shift·conv(x) true, and a correct-but-different filter (per-position weights) lacks it. That is the exact profile a keeper needs — supplement (a correct alternative lacks it), structural (an output-relation under the group), enacted (untie the weights → the property dies). The panel's question: is this a genuine 6th axis (“the output carries the input's symmetry, by construction”), or does it collapse into invariance-is-witnessed (B38) once you note that any shared-kernel filter is equivariant (coextensive with “is a convolution”)? The sharpest enacted-vs-witnessed test the campaign has fielded.