bcd019b · atomspace-gpu

Changed files (1) +139 -0

spec/convergence-with-linas.md +139 -0

…	…	@@ -0,0 +1,139 @@
	1	# Convergence with Linas — synthesis v2
	2
	3	Status: DESIGN (2026-07-05). Extends `activegraph-synthesis.md` (v1) and
	4	`hyperstoragenode.md`. Written after grounding in Linas Vepstas's current diary
	5	(`learn-lang-diary` part-ten-H/I, July 2026), the `agents`/`sensory`/`motor`
	6	projects, and an audit of our own existing GPU kernels. Read this one first.
	7
	8	## What changed since v1
	9	v1 framed the work as event-source the graph, checkpoint the Values, with the
	10	GPU Values slice-table (Linas Step 4) as the open piece. Grounding in his current
	11	writing refines this substantially:
	12
	13	1. His live frontier is the agent's DECISION DYNAMICS, not storage. He is
	14	building a measure-preserving finite automaton (unifying DFA/PFA/QFA under a
	15	"geometric finite automaton"): a state space with a measure, a menu of
	16	transformations `{Tₐ}`, and exactly one `Tₐ` fired per tick = "selecting one
	17	possible future." Selection is by self-organized criticality (abelian
	18	sandpile avalanche). His stated top priority: *"algebraicize the agential
	19	model."* Our v1 plan is storage/projection-centric and under-weights this.
	20	2. Connectors are fractal/power-law, and strengths may not be scalar. *"the
	21	jigsaw is not a small finite number of tabs, but more like velcro, a burr…
	22	Zipfian."* "there's no single number to represent the size of the jigsaw tabs."
	23	So the Values slice-table can't stay `float32`-only long-term (ordinal +
	24	"resonance/Fourier-dual"); and connector layout must be ragged/heavy-tail.
	25	3. Mating = contraction over MERGED connector-type classes (a pre-sheaf).
	26	clique → erase edges → saw into jigsaws → label = sheaf (unique reassembly);
	27	merge labels into classes = pre-sheaf = a generative grammar (many
	28	assemblies). This is the precise semantics of `mating = SpGEMM`.
	29	4. Build direction: agents crawling a corpus, not batch. *"the batch processing
	30	must be replaced by agents… that is absolutely the correct design point."* The
	31	minimal case: *"the simplest sensor detects word-pairs, and the world-model is
	32	the sparse matrix of observed counts."* Never prune low counts ("deleterious").
	33	5. Pure Atomese. His `agents` project wants algorithms written in Atomese and
	34	moved through StorageNodes — and *"StorageNodes are not just for disk storage,
	35	but for inhabiting the network cloud."* That sentence directly validates our
	36	HyperStorageNode leg.
	37	6. We already have the compute. Our own (unpushed) `atomese-simd` commits hold
	38	~12k lines of GPU kernels + tests covering exactly counting, MI, sections,
	39	cosine, connector-rewrite, and a learning loop. The MI kernel is **formula-
	40	verified `== opencog`** (see below). The GPU prong is largely audit-and-verify,
	41	not build.
	42
	43	## The unifying picture
	44	> His automaton is the mind; our stack is the body. His measure-preserving
	45	> automaton (menu `{Tₐ}` + criticality selector) runs on our substrate (a
	46	> GPU-accelerated, P2P-federated, event-sourced world-model of sections-with-values).
	47	> The shared middle is Values/Sections/Mating — his measure-preserving
	48	> transformations `{Tₐ}` are our GPU kernels; `mating = SpGEMM` is one `Tₐ`; the
	49	> selector is criticality over the Values.
	50
	51	This reunifies our two threads: the GPU-audit prong is the shared middle; the
	52	basal/world-model prong is the substrate his automaton needs.
	53
	54	## Convergence principles (how we work alongside him)
	55	1. Non-destructive. Never push to his repos; never modify his data or upstream.
	56	All work lives in OUR repo (`atomspace-gpu`) as demos. If a demo is good, expect
	57	him to rewrite it his way — that is a success, not a loss.
	58	2. Reproducible of his results. Every kernel/result is gold-checked `== opencog`
	59	ground truth — first the formula, then the numbers on real data. "Verified
	60	against a reference we wrote" is not enough (the June post-mortem trap); the
	61	reference must be tied to the real opencog engine (`matrix`/`learn`).
	62	3. Complementary. We build the infrastructure he lacks and has asked for —
	63	P2P federation, reproducible replay/fork/lineage, GPU-to-sandpile-scale
	64	— beneath his decision-dynamics, not competing with them.
	65
	66	## Two prongs, paired (not sequential)
	67	- Theory prong — reproduce the underlying computation `== opencog`, correctness
	68	first, CPU is fine.
	69	- GPU prong — the same computation on GPU, so scale/emergence is reachable.
	70	Emergence matters: criticality/avalanche phenomena may only appear at scales CPU
	71	never reaches, so GPU is sometimes load-bearing for the result, not just speed.
	72
	73	Both prongs share one verification target per primitive.
	74
	75	## The refined stack (layers, bottom-up)
	76	```
	77	Substrate (ours, the body)
	78	├─ GpuAtomTable + incoming-set CSR structure index (built)
	79	├─ Values slice-table (SoA, per-key) the payload (Step 4; f32 now, extensible)
	80	├─ HyperStorageNode (event-sourced log) reproducible replay/fork/lineage (M0-M4 built)
	81	└─ P2P federation (autobase) a society of bounded agents (M4 built)
	82	Compute / shared middle (his transforms = our kernels)
	83	├─ counting, MI = Values dynamics (gpu-counting/gpu-mi; MI formula-verified)
	84	├─ sections = germ-as-tensor (gpu-sections; unaudited)
	85	└─ connector-rewrite = mating / SpGEMM (gpu-connector-rewrite; unaudited)
	86	Automaton (his mind, our stub)
	87	├─ menu {Tₐ} one kernel per tick
	88	└─ selector max-weight → softmax → sandpile-avalanche (pluggable)
	89	(Long-term) kernels are compilation targets of pure Atomese, not hand-written.
	90	```
	91
	92	## Where v1 was right / incomplete
	93	- RIGHT: world-model = generative sheaf of sections; mating = contraction; comms =
	94	entrainment; Atom/Value split; event-sourcing answers his reproducibility pain.
	95	These match his current model.
	96	- INCOMPLETE: no decision-dynamics/selector layer (his frontier); Values assumed
	97	scalar; reactive behaviors were hand-written kernels, not Atomese-as-data.
	98
	99	## What we already have (inventory)
	100	- `atomspace-gpu` (this repo): GpuAtomTable + incoming-CSR + single-var GPU query
	101	(verified `== cog-execute!`); HyperStorageNode M0-M4 (`experiments/m0-uds-bridge/`).
	102	- `atomese-simd` (local, unpushed): 7 OpenCL kernels (`gpu-{atomspace,cosine,counting,
	103	hashtable,mi,sections,substitute}.cl`) + CUDA learning pipeline
	104	(`gpu-{connected-components,connector-rewrite,divergence,learning-loop,
	105	spanning-forest}.cu`), each with a test.
	106	- MI verification: opencog `matrix/compute-mi.scm:101`
	107	`MI = log₂[ p(x,y)/(p(x,)p(,y)) ] = log₂[ N(x,y)·N/(N(x,)·N(,y)) ]`; our
	108	`test-mi.c` `cpu_mi = log₂(count·n/(left·right))` — identical (formula level).
	109	Empirical (2026-07-05): `test-mi.c` builds (`gcc … -lOpenCL -lm`) and runs on
	110	the RTX 2070 → 6/6 PASS, ~255M pairs/s, 0 CPU↔GPU transfers; GPU MI `== cpu_mi`.
	111	So GPU `== cpu ==` opencog by formula, and the kernel provably runs+passes here.
	112	REMAINING: data-level tie — run the same counts through opencog `batch-all-pair-mi`
	113	and diff the actual numbers (Step 1b).
	114
	115	## Next steps (ordered, verification-first)
	116	1. MI: prove the kernel runs + data-verify `== opencog`. (a) ✅ DONE 2026-07-05 —
	117	`test-mi.c` builds & runs on the RTX 2070, 6/6 PASS, GPU MI `== cpu_mi`. (b) reproduce
	118	the SAME counts through opencog's `matrix` (`batch-all-pair-mi`) in guile and diff the
	119	numbers against the GPU output. Converts formula-verified → data-verified. THE
	120	cornerstone of "reproducible of his results."
	121	2. Audit `gpu-sections.cl` — is its test tied to real `learn` pseudo-csets
	122	(Section = word + ConnectorSeq, count on the Section)? Tie or fix.
	123	3. Audit `gpu-connector-rewrite.cu` — does it implement the pre-sheaf
	124	(type-class merge) mating semantics? Tie to opencog rewrite / matrix.
	125	4. Selector stub — a `{Tₐ}` dispatch loop over the verified kernels: one fired
	126	per tick, selection pluggable (max → softmax → avalanche). The first runnable
	127	piece of his automaton, on verified transforms.
	128	5. Wire to substrate — Values across the swarm via HyperStorageNode; then
	129	attention/ECAN as a real selector; then pure-Atomese compilation of kernels.
	130
	131	Do NOT: write new speculative GPU code before auditing what we have; assume scalar
	132	Values are final; push anything at his upstream.
	133
	134	## Provenance
	135	VERIFIED (his verbatim words, diary part-ten-H/I with locators, via sub-agent reads;
	136	`matrix/compute-mi.scm` MI formula read directly; the repudiation
	137	`atomese-simd@b8be282`). INFERRED: the his-automaton-on-our-substrate mapping, the
	138	layer stack. UNBUILT: the selector, the data-level MI verification, sections/mating
	139	audits.

atomspace-gpu commits / bcd019b

Changed files (1) +139 -0