From c489d6654a446e9cb570c7c4a343a1b77d8a027a Mon Sep 17 00:00:00 2001 From: AdaWorldAPI Date: Sun, 25 Oct 2026 01:05:52 +0200 Subject: [PATCH 1/2] docs(research): nsl-dr3-hypercube hypothesis and falsification gates --- .../2026-10-25/06-dr3-axes-spatial-focus.md | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 research/2026-10-25/06-dr3-axes-spatial-focus.md diff --git a/research/2026-10-25/06-dr3-axes-spatial-focus.md b/research/2026-10-25/06-dr3-axes-spatial-focus.md new file mode 100644 index 0000000..bbc3f02 --- /dev/null +++ b/research/2026-10-25/06-dr3-axes-spatial-focus.md @@ -0,0 +1,35 @@ +# DR³ addressing: a falsifiable hypercube rather than an assumed tensor engine + +Status: RESEARCH PROPOSAL, unimplemented. DR64³ / DR256³ are architectural hypotheses. + +## Hypothesis +A 3-axis relational address space may host identity, relation/property and time/channel/model dependencies in pages, while active focus traverses only relevant tiles. Different datasets may require different axis semantics; rank-3 address space is NOT equivalent to arbitrary tensor rank. + +## Explicit arithmetic +- 64^3 = 262,144 logical cells; at 1 bit/cell = 32 KiB dense. 256^3 = 16,777,216 cells = 2 MiB dense bitmask. +- A DR256² plane has 65,536 cells = 8 KiB at 1 bit/cell; 256 planes require 2 MiB. Attribute values, sparse index, pointer overhead and cache structures are additional. +- Earlier DR focus work (#1762) stores gathered i32 facet columns. It does NOT implement a DR³ cube. + +## Probe matrix +A. Node x node x relation-type planes on tiny typed graph. +B. Node x feature x temporal step on synthetic event stream. +C. Neural dependency indices x operator channel x quantized parameter family from a fixed tiny model. +D. Deliberately adversarial skewed/sparse graph, to test whether 3D tiling is worse than CSR/COO/SoA. + +## Method +1. Specify canonical address and reversibility, Morton/HHTL mapping only if proven bijective for populated range. +2. Define per-axis ID mapping, tile bounds, eviction and branch/index seals; forbid reuse across incompatible scope. +3. Compare query correctness against a plain adjacency-list + sparse SoA oracle for each matrix, including missing and duplicate cells. +4. Benchmark memory footprint, cache/TLB misses, load time, active focus fraction, cold/warm traversal and update cost. +5. Perturb one tile; measure actual invalidation footprint and correctness under concurrent readers. + +## Falsifiers +- Any aliasing of logical coordinates or silent overflow is rejection. +- Report worst-case sparse memory blowup; no 1/16 focus benefit assumption. +- Compare against optimized CSR and dense bitmap baselines, not only a naive array. +- Independent verification of layout; no claim of general tensor replacement without rank-4+/broadcast/stride/quantization semantics covered. + +## Dependencies +lance-graph #1762 focus lease and seals; ndarray #372-375 low-level SIMD/quantized kernels may be reused but do not validate layout. + +References: https://github.com/AdaWorldAPI/lance-graph/pull/1762 ; https://github.com/AdaWorldAPI/ndarray/pull/375 From 1a4ccf54a31876dad638d8a3522debcc8644ead4 Mon Sep 17 00:00:00 2001 From: AdaWorldAPI Date: Sun, 25 Oct 2026 01:18:30 +0200 Subject: [PATCH 2/2] docs(research): detailed experiment contract for DR3 bit-addressing and negative sparse workloads --- .../06a-dr3-layout-and-address-proof.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 research/2026-10-25/06a-dr3-layout-and-address-proof.md diff --git a/research/2026-10-25/06a-dr3-layout-and-address-proof.md b/research/2026-10-25/06a-dr3-layout-and-address-proof.md new file mode 100644 index 0000000..ccf8333 --- /dev/null +++ b/research/2026-10-25/06a-dr3-layout-and-address-proof.md @@ -0,0 +1,74 @@ +# H6 / DR³ hypercube: reversible addressing and adversarial sparsity + +**Status:** proposed address/layout experiment; not proof that a hypercube engine exists. Companion to [PR #6](https://github.com/AdaWorldAPI/neural-structured-learning/pull/6). + +## What a cube may mean + +Hypothesis: a 3-axis relation index can preserve **typed identity and dependency semantics** while traversing only occupied/focused subregions. + +Candidate domains are **alternative views**, not a single implied universal schema: +- U × U × R: source identity, target identity, relation type. +- U × P × T: identity, property/facet, logical time bucket. +- Operator × InputPort × OutputPort: computational graph dependency. +- DirectionA × DirectionB × RuleFamily: quantized pair operation by context. + +No rule says "axis 3 means time" across all workloads. Every view must carry a typed domain signature and an invertible ordinal dictionary. A rank-3 bitcube is not an arbitrary-rank dense tensor value store. + +## Exact capacity and bit addressing + +DR64³: 64³ = 262,144 logical Boolean cells = 32 KiB dense bit storage. +DR256³: 256³ = 16,777,216 cells = 2 MiB dense bit storage. +A 256×256 plane is 65,536 cells = 8 KiB of bits; 256 such planes are 2 MiB, before headers/metadata/values. + +Candidate contiguous flat index: + index(x,y,z) = (x * Y + y) * Z + z for x∈[0,X), y∈[0,Y), z∈[0,Z). + +Candidate equal-width Morton index: + morton3(x,y,z) = Σ_i ((x_i << (3i)) | (y_i << (3i+1)) | (z_i << (3i+2))). +For 64³ use 6 bits/axis -> 18-bit index. For 256³ use 8 bits/axis -> 24-bit index. The bit interleave should be independently inverted; do **not** assume 2D HHTL Morton routines already implement 3D ordering. + +Prove that decode(encode(x,y,z)) = (x,y,z) for every admitted coordinate. For DR64³ an exhaustive 262,144-coordinate test is straightforward. For DR256³ sample plus boundary/permutation fixtures initially, with an exhaustive test only if runtime budget permits. + +Define bit index, byte order and publication/revision digest; a wrong endian convention can appear correct in uniform-mask tests. + +## Data cannot disappear behind an address + +- Presence Boolean vs null/missing vs typed value plane is explicitly represented. +- A 1-bit presence cube with 16,777,216 cells is 2 MiB; an f32 value at every populated cell would add up to 64 MiB for a fully dense 256³ cube. +- Value SoA, sparse value ordinals, compression, tile metadata, source dictionaries and stale-frame checks have separate measured storage costs. +- A relation code and neural activation may occupy the same addressing abstraction, but their algebraic semantics are different. No "neuron = fact" shortcut. + +## Candidate focus/paging variants + +A. Dense bitcube with direct bit index. +B. 2D DR256² planes, sparse third-axis directory. +C. 16³ tiles with per-tile occupancy mask and sparse directory; 16³ Boolean tile is 512 bytes. +D. CSR/COO adjacency + SoA payload reference baseline, with optional roaring-like bitset or partitioned sorted vectors. +E. #1762-inspired materialized focus lease: full SourceId + MapId + Scope, with own invalidation and dirty-flush behavior explicitly *not yet verified*. + +For a view with only 1 out of 256 third-axis slices occupied, dense 2 MiB may be very poor value compared with sparse 8 KiB plane plus directory. In a dense hot neighborhood, direct indexing may win. + +## Preregistered workload matrix + +| ID | Shape | Expected failure surface | +| --- | --- | --- | +| C01 | completely dense, read-many | directory overhead vs dense bit arithmetic | +| C02 | 0.01% uniform random occupancy | dense memory blowup | +| C03 | 1% occupancy in 1/16 tiles | measured focus benefit vs tile lookup cost | +| C04 | adversarial diagonal-only relations | sparse CSR/COO likely better | +| C05 | power-law hub degree | uneven tile utilization and cache churn | +| C06 | 90% relations on one hot plane | plane directory may beat 3D tiling | +| C07 | frequent edits to one temporal plane | invalidation / stale lease costs | +| C08 | same ordinal reused with changed source seal | must refuse | +| C09 | two equal data populations, differing axis permutations | locality must be measured for each axis order | +| C10 | all boundary coordinates and tile crossings | zero collisions and exact inverse map | + +## Independent correctness and cost oracle + +Use a plain typed triple set plus sorted map as semantic oracle. Compare insert/delete/contains, enumeration, range/focus query, union, intersection and relation composition only where those operations are truly defined for the typed domains. Do not claim a generic "tensor MatMul" follows from Boolean relation composition. + +Metric columns: logical cells, nonzero occupancy, dense/SoA/directory bytes, resident bytes, page faults, p50/p95/p99 latency, update invalidation, cold/warm focus, CPU cache misses, throughput. + +## Go/no-go + +Any coordinate collision, silent alias, invalid seal accepted, or untracked distinction between absent and zero is a correctness failure. If cost loses to CSR across practical sparsities, reject that layout for those workloads. **The earlier 1/16 focus ratio is a workload hypothesis, not a storage guarantee or theorem.**