> Full-text translation from Chinese. The original remains authoritative for its research claims; this translation is not independent mathematical verification.

# X4-DMSD P2: Shared-Edge Scale Coupling Engine

**Exact Shared-Edge Scale Coupling Engine for Indexed X4 Joint Search**

Version: v0.1  
Series: X4-DMSD  
Phase: P2  
Nature: Exact join engine / ratio indexing / bounded benchmark / Euler-brick regeneration  
Canonical source of the original: UTF-8 Markdown

---

## Abstract

X4-DMSD P1 compressed global compatibility of three oriented primitive Pythagorean face joints into:

$$
ACB'=BC'A'.
$$

P2's goal is to compile this identity from a "decision formula" into an efficient exact join engine.

If the naive method has:

$$
N
$$

oriented joints, it enumerates:

$$
N^3
$$

instances of:

$$
(J_{ab},J_{ac},J_{bc})
$$

those combinations.

P2 rearranges the coupling identity:

$$
ACB'=BC'A'
$$

as:

$$
\boxed{
\frac{B'}{C'}
=
\frac{BA'}{AC}.
}
$$

Each $J_{bc}$ can therefore first have a hash index built using its exact reduced ratio:

$$
R_{bc}
=
\frac{B'}{C'}
$$

as the index key.

Thereafter, each pair:

$$
(J_{ab},J_{ac})
$$

needs only to compute the required key:

$$
\boxed{
R_{\mathrm{req}}
=
\frac{BA'}{AC}
}
$$

and perform a direct lookup.

The explicit search work therefore changes from:

$$
O(N^3)
$$

to:

$$
\boxed{
O(N^2+\text{hash matches})
}
$$

under the current implementation model.

P2 uses primitive Euclid seeds with:

$$
m\le80
$$

retaining both ordered leg orientations, and actually generates:

$$
2628
$$

X4 joints.

Size of the naive oriented-triple space:

$$
\boxed{
18,149,977,152.
}
$$

The P2 engine actually issues only:

$$
\boxed{
6,906,384
}
$$

ordered pair queries, and exact ratio lookup returns only:

$$
\boxed{
288
}
$$

raw compatible oriented triples.

These canonicalize into:

$$
\boxed{
48
}
$$

unique Euler-brick edge worlds.

There is no PerfectClick hit among them; this is only a bounded result.

P2 also performs, in the tractable range $m\le15$, a complete $N^3$ brute-force cross-check, showing that the indexed engine's raw compatible triple count and unique Euler-brick set agree exactly.

This round therefore verified:

$$
\boxed{
\text{Ratio-indexing acceleration did not rely on omitting compatible triples.}
}
$$

---

# 1. P1 Coupling Identity

Three joints:

$$
J_{ab}=(A,B,H_{ab}),
$$

$$
J_{ac}=(A',C,H_{ac}),
$$

$$
J_{bc}=(B',C',H_{bc}).
$$

Compatible if and only if:

$$
\boxed{
ACB'=BC'A'.
}
$$

---

# 2. Solve for the Missing Joint Ratio

Suppose the following are known:

$$
J_{ab},
J_{ac}.
$$

Then:

$$
ACB'=BC'A'
$$

can be rewritten as:

$$
\boxed{
\frac{B'}{C'}
=
\frac{BA'}{AC}.
}
$$

The right-hand side is determined entirely by the first two joints.

There is therefore no need to enumerate the third joint.

Only:

$$
\boxed{
\operatorname{lookup}
\left(
\frac{BA'}{AC}
\right).
}
$$

---

# 3. Exact Ratio Key

Define:

$$
K_{bc}(J)
=
\operatorname{Reduce}
(B',C').
$$

That is, the reduced rational key of:

$$
\frac{B'}{C'}
$$

that ratio.

An implementation can use the canonical pair:

$$
\left(
\frac{B'}{\gcd(B',C')},
\frac{C'}{\gcd(B',C')}
\right).
$$

For primitive Pythagorean joints:

$$
\gcd(B',C')=1,
$$

but general reduction semantics are still retained.

---

# 4. Required Ratio Key

Given a pair:

$$
(J_{ab},J_{ac}),
$$

define:

$$
\boxed{
K_{\mathrm{req}}
=
\operatorname{Reduce}
(
BA',
AC
).
}
$$

If the index contains no:

$$
K_{\mathrm{req}},
$$

the entire:

$$
J_{bc}
$$

candidate domain is immediately empty.

---

# 5. Proposition P2-A: Indexed Join Completeness

If the ratio index contains all candidate:

$$
J_{bc},
$$

then:

$$
K_{bc}
=
K_{\mathrm{req}}
$$

if and only if:

$$
ACB'=BC'A'.
$$

Exact ratio-hash lookup is therefore sound and complete for the P1 coupling relation.

---

# 6. Proof

$$
K_{bc}=K_{\mathrm{req}}
$$

is equivalent to:

$$
\frac{B'}{C'}
=
\frac{BA'}{AC}.
$$

Cross-multiply:

$$
ACB'=BC'A'.
$$

The converse is analogous.

There is therefore no heuristic loss in lookup.

---

# 7. Join Engine

P2 engine:

```text
index = map ratio(B',C') -> list[J_bc]

for J_ab in joints:
    for J_ac in joints:
        required = reduce(B*A', A*C)
        for J_bc in index[required]:
            emit exact compatible triple
```

---

# 8. Complexity

Build the index:

$$
O(N).
$$

Pair emissions:

$$
N^2.
$$

If total hash matches number:

$$
M,
$$

then:

$$
\boxed{
T_{\mathrm{join}}
=
O(N^2+M).
}
$$

Compared with the naive method:

$$
O(N^3).
$$

This is a reduction in algorithmic work. It does not mean complete Perfect Cuboid search already has the same asymptotic bound; subsequent DMSD, height growth and multilayer indexing still need separate analysis.

---

# 9. Why Multiple Matches May Exist

If different local joints have the same:

$$
B'/C'
$$

ratio,

the same hash bucket can contain multiple states.

One therefore cannot store just a single joint.

The index value must be a:

$$
\boxed{
\text{list / bucket}.
}
$$

---

# 10. Bucket Semantics

$$
I_R
:
R
\mapsto
\{J_1,\ldots,J_k\}.
$$

This lets scale duplicates, different seed representations or future block summaries belong to the same ratio class.

---

# 11. Role-Aware Index

One cannot store only an unlabelled triangle ratio.

For:

$$
J_{bc},
$$

the key must know:

- The numerator is the $b$-role;
- The denominator is the $c$-role.

If one swaps:

$$
B'\leftrightarrow C',
$$

the key becomes reciprocal.

The P2 index is therefore oriented.

---

# 12. Why Orientation Is Necessary

P1's Euler-brick role-swap negative control verified:

local Pythagorean validity remains after a role swap,

but global coupling may fail.

Thus:

$$
\boxed{
\text{shape key}
\neq
\text{role-aware coupling key}.
}
$$

---

# 13. Pair-First Join

P2 chooses:

$$
(J_{ab},J_{ac})
$$

as its pair emitter.

But the identity can also be solved as:

$$
\frac{A'}{C}
=
\frac{AB'}{BC'},
$$

or other equivalent forms.

The engine can therefore dynamically choose:

$$
\boxed{
\text{The smallest bucket / sparsest key orientation}.
}
$$

---

# 14. Adaptive Join Ordering

Future work can estimate bucket distributions for three indices:

- $A'/C$;
- $B'/C'$;
- $A/B$.

Choose the direction with the smallest expected match count.

This resembles a database query optimizer, but equality semantics remain exact.

---

# 15. Prime-Valuation Key

Coupling identity:

$$
ACB'=BC'A'
$$

For a prime:

$$
p
$$

it gives:

$$
v_p(A)
+
v_p(C)
+
v_p(B')
=
v_p(B)
+
v_p(C')
+
v_p(A').
$$

Besides the full rational-ratio key, one can therefore store:

$$
\boxed{
V_{\mathcal P}(J)
}
$$

as a coarse pre-index.

---

# 16. Modular Key

For a modulus:

$$
M,
$$

a necessary condition is:

$$
ACB'
\equiv
BC'A'
\pmod M.
$$

A cheap modular screen can precede expensive big-integer Fraction construction.

The P2 prototype currently uses the exact rational key directly, prioritizing correctness validation.

---

# 17. Euler-Brick Regeneration

After a triple matches,

P1's explicit scales:

$$
k_{ab}=A'B',
$$

$$
k_{ac}=AB',
$$

$$
k_{bc}=BA'
$$

construct a raw Euler brick directly.

Then divide by:

$$
G
=
\gcd
(
a,b,c,d_{ab},d_{ac},d_{bc}
).
$$

to obtain a primitive representative.

---

# 18. Canonical World Key

The P2 prototype uses:

$$
\boxed{
\operatorname{sort}(a,b,c)
}
$$

as a unique Euler-brick edge key.

The edges uniquely determine the face diagonals.

This removes:

- local-joint role permutations;
- repeated construction paths;
- common scale duplicates.

---

# 19. Body Gate

Every unique Euler brick then receives the exact check:

$$
a^2+b^2+c^2
\stackrel{?}{=}
g^2.
$$

Only if true:

$$
\operatorname{PerfectClick}=1.
$$

---

# 20. Search Layers

P2's actual pipeline:

$$
\boxed{
\text{primitive seeds}
\rightarrow
\text{oriented joints}
\rightarrow
\text{ratio index}
\rightarrow
\text{pair emission}
\rightarrow
\text{hash lookup}
\rightarrow
\text{compatible triple}
\rightarrow
\text{Euler brick}
\rightarrow
\text{body gate}.
}
$$

---

# 21. Bounded Seed Domain

This round defines:

$$
2\le m\le M,
$$

$$
1\le n<m,
$$

$$
\gcd(m,n)=1,
$$

and:

$$
m-n
$$

is odd.

Each primitive seed produces two ordered orientations.

---

# 22. $M=80$ Joint Count

This gives:

$$
\boxed{
N=2628
}
$$

oriented X4 joints.

---

# 23. Naive Triple Space

If one actually computes:

$$
N^3,
$$

then:

$$
2628^3
=
\boxed{
18,149,977,152.
}
$$

This is only the number of oriented local-joint combinations.

---

# 24. Indexed Pair Space

P2 needs only:

$$
N^2
=
2628^2
=
\boxed{
6,906,384.
}
$$

pair emissions.

Ratio to the naive triple count:

$$
\frac{N^2}{N^3}
=
\frac1N
\approx
3.805\times10^{-4}.
$$

---

# 25. Hash-Matched Compatible Triples

Among:

$$
6,906,384
$$

pair queries, the exact ratio buckets return a total of:

$$
\boxed{
288
}
$$

raw compatible oriented triples.

Relative to the naive triple space:

$$
\frac{288}{18,149,977,152}
\approx
1.5868\times10^{-8}.
$$

The coupling relation is therefore extremely sparse in this bounded corpus.

---

# 26. Unique Euler Bricks

After canonicalizing 288 oriented construction paths, only:

$$
\boxed{
48
}
$$

unique edge worlds remain.

---

# 27. Perfect Hits

This round has:

$$
\boxed{
0
}
$$

body-square closures.

This holds only for the local seed corpus with:

$$
m\le80
$$

that bound.

It cannot be extrapolated to nonexistence of a Perfect Cuboid.

---

# 28. Known Euler Brick Recovery

The M80 corpus reconstructs exactly:

$$
\boxed{
(44,117,240)
}
$$

and other known Euler-brick worlds.

The indexed engine therefore does not produce only artificial coupling examples.

---

# 29. Brute-Force Completeness Cross-Check

To validate that the ratio index omits no matches,

P2 additionally performs, at:

$$
M=15
$$

a complete:

$$
N^3
$$

triple enumeration.

For that range:

$$
N=94.
$$

Naive tests:

$$
94^3
=
830584.
$$

---

# 30. Cross-Check Result

Naive and indexed methods have:

- Identical raw compatible triple counts;
- Identical unique Euler-brick sets.

Thus:

$$
\boxed{
\text{P2 indexed join passes bounded completeness cross-check.}
}
$$

---

# 31. Benchmark Growth

P2 also tests:

$$
M
\in
\{15,20,30,40,60,80\}.
$$

All detailed data are stored in:

`benchmark_summary.json`.

The purpose is not to establish a hardware-independent performance theorem,

but to observe:

- joint count；
- pair count；
- compatible density；
- Euler-brick yield.

---

# 32. Runtime Measurement Warning

Actual elapsed seconds depend on:

- Python runtime;
- CPU;
- hashing;
- Fraction implementation;

and their effects.

P2 therefore does not turn wall time into a mathematical claim.

The main comparison is:

$$
N^3
$$

against:

$$
N^2+M.
$$

---

# 33. Query-Planning Interpretation

The X4 coupling engine can essentially be viewed as a relational join:

```text
AB(A,B)
AC(A',C)
BC(B',C')
```

Constraint:

```text
A*C*B' = B*C'*A'
```

P2 rewrites it as an equi-join:

```text
BC.ratio = required_ratio(AB,AC)
```

X4 world search thus begins to acquire a database-like query-optimization structure.

---

# 34. Why This Is Important for DMSD

DMSD blocks need not store every triple.

They can store:

$$
\boxed{
\text{ratio-key support}.
}
$$

If the required ratio emitted by a two-block pair is absent from the third block's support,

prune the whole hyperblock directly.

---

# 35. Block Ratio Support

For a block:

$$
B_{bc},
$$

define:

$$
\mathcal R_{bc}(B)
=
\left\{
\frac{B'}{C'}
:
J_{bc}\in B
\right\}.
$$

Pair blocks:

$$
B_{ab},
B_{ac}
$$

produce:

$$
\mathcal R_{\mathrm{req}}
=
\left\{
\frac{BA'}{AC}
\right\}.
$$

If:

$$
\mathcal R_{\mathrm{req}}
\cap
\mathcal R_{bc}
=
\varnothing,
$$

then:

$$
\boxed{
B_{ab}\bowtie B_{ac}\bowtie B_{bc}
=
\varnothing.
}
$$

---

# 36. Proposition P2-B: Ratio-Support Block Pruning

If block summaries include all possible ratio keys exactly,

and:

$$
\mathcal R_{\mathrm{req}}
\cap
\mathcal R_{bc}
=
\varnothing,
$$

the triple block contains no P1-compatible joint triple.

This pruning is therefore sound.

---

# 37. Compression Challenge

If the block's ratio support is itself enormous,

listing every ratio directly loses DMSD's advantage.

Subsequent work therefore needs:

- interval / Farey summaries；
- modular projections；
- valuation signatures；
- algebraic seed-range bounds;

as compact support representations.

This is the focus of P3–P5.

---

# 38. Pair Cache

The same:

$$
K_{\mathrm{req}}
$$

may be generated repeatedly by many pair emissions.

One can therefore cache:

$$
K_{\mathrm{req}}
\mapsto
I_R[K_{\mathrm{req}}].
$$

A subsequent DMSD distributed runtime can share it.

---

# 39. Canonical Fraction vs Integer Pair

The Python prototype uses:

$$
\operatorname{Fraction}.
$$

For an efficient implementation, a reduced integer pair is suggested instead:

$$
(p,q),
$$

with a custom hash to avoid generic Fraction overhead.

---

# 40. Overflow

Because X4-DMSD will eventually span enormous heights,

it cannot rely on fixed-width:

$$
64\text{-bit}
$$

integers.

A formal runtime needs:

- big integers;
- modular prefilters;
- delayed exact multiplication.

---

# 41. Cross-Multiplication Overflow Avoidance

Deciding:

$$
ACB'=BC'A'
$$

when the numbers are enormous,

one can first:

1. reduce gcd factors;
2. compare valuations;
3. reject modularly;
4. finally use big-int exact equality.

This will become a P3 engine optimization.

---

# 42. GCD Cancellation

The required ratio:

$$
\frac{BA'}{AC}
$$

should cross-cancel gcd factors before multiplication.

For example, first use:

$$
g_1=\gcd(B,A),
$$

$$
g_2=\gcd(A',C),
$$

then reduce.

This can substantially limit intermediate bit length.

---

# 43. PerfectClick Remains Exact

Every join optimization can change only:

$$
\text{how fast candidates are reached}.
$$

It cannot change the final:

$$
\operatorname{PerfectClick}.
$$

An exact body-square test is still required in the end.

---

# 44. P2 Correctness Contract

Every future optimization must guarantee:

### Soundness

An emitted triple must genuinely satisfy:

$$
ACB'=BC'A'.
$$

### Completeness

Every compatible triple in the corpus must be emitted.

### Canonicalization Safety

Removal of scale / permutation duplicates must not delete distinct edge worlds.

---

# 45. P2 Validation Artifacts

The bundle contains:

- `x4_coupling_engine.py`
- `benchmark_summary.json`
- `euler_bricks_m80.csv`

All use exact integer / rational operations.

---

# 46. Summary of P2's Core Results

### P2-R1

The coupling identity can be rewritten as an exact ratio equi-join.

### P2-R2

Under the implementation model, indexed join complexity decreases from explicit $N^3$ to:

$$
O(N^2+M).
$$

### P2-R3

At $M=15$, the brute-force cross-check agrees exactly with the indexed engine.

### P2-R4

At $M=80$:

$$
N=2628,
$$

$$
N^3=18,149,977,152,
$$

$$
N^2=6,906,384,
$$

$$
288
$$

raw compatible triples,

$$
48
$$

unique Euler bricks,

$$
0
$$

Perfect hits.

---

# 47. What P2 Does Not Claim

P2 does not claim:

- That complete Perfect Cuboid search complexity has decreased to $O(N^2)$;
- That X4-DMSD already spans enormous decimal scales;
- That ratio buckets retain the same sparsity at high height;
- That indexed join already outperforms every existing Euler-brick algorithm;
- That a Perfect Cuboid does not exist.

---

# 48. Updating the Original "Mortise-and-Tenon" Intuition

P1:

$$
\text{Can they click?}
$$

becomes:

$$
ACB'=BC'A'.
$$

P2:

$$
\text{Must I try the third piece one at a time?}
$$

The answer becomes:

$$
\boxed{
\text{No. The first two pieces directly determine the exact tenon ratio the third must have.}
}
$$

Then perform a hash lookup.

This is the first genuine conversion of "examining interfaces" into search acceleration.

---

# 49. Next Phase

**X4-DMSD P3 — Ratio/Valuation/Modular Signature Engine**

P3 should begin turning exact ratio lookup into a huge-scale-ready form:

1. reduced integer ratio key;
2. pre-multiplication gcd cancellation;
3. prime valuation vector;
4. modular ratio signature;
5. bucket intersection;
6. bit-length accounting;
7. false-negative-free prefilter;
8. comparison with a plain Fraction index;
9. block-compatible summary format;
10. DMSD handoff interface.

Only after P3 is complete should the P2 engine actually be embedded in DMSD blocks.