reading store snapshot…
one network - projects/neocognitron - client-side, no build, no server

neocognitron

Fukushima's 1980 self-organizing multilayered network, every equation from the paper, training live in this page with no labels and no backprop. Four stages of S-cells (feature extractors, one shared kernel per plane) and C-cells (position-tolerant pooling). Watch the planes organize themselves, click any cell to see the retina it answers to, then point the same machinery at one-cortex - Leon's own memory store - and watch that organize itself.

1. Retina and training

draw with the pointer (shift / right button erases). Amber = the selected cell's template projected to the retina, red = its footprint.
beside it, the same retina moved 2 px to each of the eight compass points and run through the network as it stands right now: each tile is what the network was shown and the number under it is the UC4 plane that won there. Teal = the same plane as the centre still wins, so the answer survived the move; coral = a different plane took it; mute = nothing answered at all. This is the claim of section 3 on whatever is on the retina at this moment, your own drawing included. Hover a tile for its margin.
last, what the retina becomes on the way up: one tile per layer, S over C for each of the four stages. Each tile is, at every position, the largest response of any of that layer's 24 planes, painted on the layer's own peak - teal for an S-layer, blue for a C-layer. Every sheet is drawn the same size although they shrink from 28 to 1 cells, so the loss of position reads as blur. UC4 is a single cell, and the amber plane on it is the answer the shift tiles test. The count is how many of the 24 planes answer at all. Hover a tile for the numbers.
what training recruits: planes reinforced per stage, epoch by epoch. Each stage only recruits while its own block runs - that is the layer-wise schedule - and the deeper stages recruit fewer planes than the shallow ones, which is where section 3's accuracy is lost.

corpus

train (unsupervised, layer by layer)

untrained: every plane still carries its weak initial orientation bias.

snapshot

output UC4

one bar per UC4 output plane, height = how loudly that plane answers the retina right now, against the loudest; the winner is amber and a plane whose S4 kernel was never reinforced is a flat stub. The foot under a bar is what section 3's measurement found that plane to BE, in the colours that panel uses: amber = exactly one digit lands there, so the plane carries that digit as a label; coral = several digits land there, so it labels none of them. Under the axis, a plane that digits land on carries its own number in a solid pill of that colour and then every one of those digits, one per line; where two pills would touch, the second drops to a lane below. Before the shift table is measured the strip is only the response. Hover a bar for both.

2. Inspector - every plane, live

Each small canvas is one cell-plane. S-planes (teal) share a single kernel across all their cells; C-planes (blue) pool overlapping windows of the S-plane below them. Every layer is laid in the same columns, plane 0 top left and reading across, so a C-plane sits straight under the S-plane of the same number it pools. The red canvas in its own column beside each layer is that layer's V-cell (the divisive inhibitor for S, the lateral mean for C). Faded S-planes have never been reinforced. While training runs, amber cells are the seeds - the winner-take-all representatives the last presentation reinforced. Click a cell to trace its receptive field down to the retina.

Every tile is painted on its own maximum, so the shape inside a quiet plane is visible instead of being crushed to black by the loudest plane beside it. The amber strip under each tile is what that costs: the plane's peak as a fraction of the layer's peak, which is the one thing a per-plane scale throws away. A full strip is the layer's winner; a strip you cannot see is a plane whose picture is real and whose response is nothing. Hover a tile for both numbers.

selected cell

nothing selected

how many planes still answer

one row per layer, 24 bars, one per plane: the height is that plane's strongest cell for the retina right now, on the row's own scale (rows are not comparable to each other). Amber is the row's winner, numbered by its plane above the bar, a flat stub is an S-plane no seed ever reinforced, and the outlined bar is the plane selected in the grid; the count at the right is how many of the 24 answer at all. Read down: the response goes from spread across two dozen comparable bars at US1 to one tall bar over a floor of near-zero ones at UC4. That concentration, not the count, is the winner-take-all - and it is what section 3's accuracy is made of.

2b. The stack in three dimensions

The same network, seen along its depth. Each sheet is one layer, tiled into its 24 cell-planes; each point is one cell, and its brightness is that cell's activation u right now - drawn straight from the live arrays, recomputed every time the retina changes. Amber is the retina, teal the S-layers (feature extractors), blue the C-layers (position-tolerant pooling). Faded planes have never been reinforced. Click a cell in the inspector above and its receptive field lights up through every layer, with red edges to the cells that feed it directly.

The sheets get smaller with depth, but that is not the thing that grows. What grows is how much of the retina one cell can see, and the ladder beside this says how much: it is measured by running the same receptive-field trace the inspector uses, down from the middle cell of each layer to the retina.

what one cell sees: the retina pixels that can reach the middle cell of each layer, traced through the real windows. Amber is the footprint, the digit behind it is the retina right now, so each tile says how much of THIS pattern that cell is looking at.
drag to orbit, wheel or pinch to zoom. Cells with no response are black, so what you see is only what the network is actually doing.

3. Measurement - does position invariance hold?

After training, each digit is assigned the UC4 plane it wins at shift 0. Accuracy at shift s is the fraction of digit presentations at the 8 compass offsets of s pixels (plus two mildly deformed variants each) whose winning plane is labelled with that digit. The control arm is an untrained network through the same procedure.

which plane each digit claimed

one row per UC4 output plane that fired, with the digit glyphs that won it at shift 0. A plane won by exactly one digit becomes that digit's label (amber); a plane won by several is a collision (coral) and every digit inside it is unlabelled, which is where the accuracy above is lost.

which way it has to move

the same measurement as the chart beside it, split by the DIRECTION the digit was moved instead of averaged over all eight. The centre is no shift; each ring out is one row of the table (1, 2, 4 and 6 px) and each wedge is one compass offset, painted by how often the same UC4 plane still wins when the digit is moved that way. Teal all round at every radius is the isotropic invariance the paper claims; the coral wedge is the direction that loses it first, which the table and the chart both average away. Stage-1 kernels are ORIENTED, so there is no reason to expect the eight directions to be equal. Hover a wedge for its count.
two different questions against how far the digit was moved from where it was learned. Teal: the SAME UC4 plane still wins - position invariance on its own, labels ignored. Amber: that plane also carries this digit's label, which is the accuracy in the table. The shaded band between them is what the collisions cost - every presentation in it kept its plane and was still counted wrong, because several digits share that plane. Coral is the untrained control through the identical procedure and the dashed line is the 0.5 the acceptance harness demands at 0 and 4 px. Position invariance is the teal line staying FLAT as the shift grows; the amber line is flat too, just held down by the band.

where the ten digits land

the whole output layer, not just its winner: one row per digit, one column per UC4 plane, the cell painted by that digit's response there on the DIGIT'S OWN peak - so a row is the shape of that digit's answer, not how loud it is, and the rows can be read against each other. The ring on each row is the plane that digit won: amber where it owns that plane alone and can be labelled with it, coral where several digits share it and none of them is. Rings stacking into the same few columns is the collapse the table above is measuring; the teal behind them says whether the runners-up were anywhere close. Measured on the weights loaded right now, not on the last shift table. Hover a cell for the number.

learned stage-1 kernels

the same 24 kernels as height fields of their own weights a(v) - amber up, blue down, flat and faded means never reinforced - laid out in the order of the row above, so the first surface is the first tile, and each one named by its plane and the axis it answers to (amber = oriented). Rebuilt from the weights after every training run; drag to turn it.

4. one-cortex - the memory store as retina and as stack

Each one-cortex chunk carries a 768-dimensional embedding. The export script arranges those 768 dimensions on the 28x28 retina so that correlated dimensions are neighbours (a PCA layout of the dimensions, assigned to grid cells), then every chunk becomes a retina image the same network can eat. Select this corpus above and train: the planes now specialise on regions of the memory.

the store in three dimensions

every chunk placed by the first three principal components of its 768-d embedding. Colour = community, size = access count, dimness = decay. The larger nodes are the 34 communities at the centroid of their own chunks, each named in its own colour where the name fits without touching another - the biggest communities first, so the cloud reads as a map; the lines are communities that share chunks, brightness by how many. Click a chunk to run it as a query - it is ringed, a card beside it carries its retina, its id and its community, always inside the frame with the names placed around it, and the panels below update.

chunk retinas

why the dimensions are arranged

what each UC4 plane specialises on

the retrieval stack, live from the store files

chunks (2D PCA of embeddings), colour = community, size = access count. The largest communities are named where there is room, by the rank the overlap matrix and the sizes list below give them, beside a small ring at the median of their own members. Click a chunk to run it as a query: the query takes the amber crosshair and its candidate pool is haloed BY RANK - the halo is widest and brightest on the nearest chunk and fades out to the 150th, white above the recall floor and grey in the gray band, so a tight neighbourhood reads as a knot and a diffuse one as a wash across the cloud.
candidate pool for the selected query: cosine over all chunks, top-150 kept, drawn on the pool's OWN score range so the two config.json floors are lines it crosses; bar colour = that chunk's community
how the store ages: decay (blue) and the three stability horizons (teal) as four histograms over 0-1, one per row, each on its OWN count scale - they do not share a maximum, so the peak of each row is printed beside it and the amber tick is that row's median.
which communities OVERLAP: rows and columns are the communities ranked by the chunks they cover (the order of the bars below), cell = how many chunks that pair shares, painted in the row's own colour; the diagonal is the community itself. BOTH axes are named - the columns run up the top edge in the same order as the rows - so a cell can be read off the page as the pair it is, instead of only the one row it sits in. Where a column is too narrow for a name at a readable size, the columns are numbered by rank and every row name starts with that rank. A row is taller than a column is wide: the width sets the column pitch, and each row gets the height its name needs, with a band on every other row to follow it across. Hover a cell for the pair and the count.

what the query pulled back

the top of that candidate pool as PICTURES instead of bars: the query's own retina first inside the amber frame, then the 23 nearest chunks in rank order, each drawn in its community's colour. All 24 tiles share ONE brightness scale, so a faint tile is a chunk with little standing out and not a per-tile scaling artefact. The strip under each tile is the cosine between that chunk's RETINA and the query's - what the pictures themselves agree on, against the embedding rank the grid is sorted by - and a chunk whose embedding cosine falls under the recall floor is drawn mute, the same floor the pool chart above draws as a line. Hover a tile for its chunk id and both numbers.

community sizes

the same 34 communities ranked by the chunks they cover - the number in front is that rank, the same number the overlap matrix above gives the community's row and column; the swatch beside it is the colour the community carries in the scatter and in the 3d store, and bar length is its chunk count as a fraction of the largest. Hover a bar for its community id and top entities.