> Full-text translation from Chinese. The original remains authoritative for its research claims; this translation is not independent mathematical verification. # Decimal Multiscale Serializable Domain: Foundational Methodology ## Decimal Multiscale Serializable Domain — Foundational Methodology **Version:** v0.1 **Date:** 2026-09-30 **Nature:** Methodology / foundational architecture paper **Provisional abbreviation:** DMSD (Decimal Multiscale Serializable Domain) --- ## Abstract This paper proposes a multiscale serializable mathematical domain organized around decimal orders of magnitude, for integer sequences and their subsequent mathematical properties that are theoretically unbounded but must be finitely closed in actual computation. The central idea is not to expand every integer at once, but first to serialize **scale itself**: \[ 10^0,\;10^1,\;10^2,\;10^3,\ldots \] Each order-of-magnitude interval is then treated as a scale block whose expansion can be deferred. This paper proposes two complementary global perspectives: 1. **Magnitude Pyramid View** 2. **Serialized Staircase View** The pyramid has two opposite traversals: - From smaller to larger scales: observe how orders of magnitude expand outward; - Set a large scale first, then look back toward smaller scales: observe how the large scale decomposes into finer scales. The staircase view emphasizes the rightward expansion of a sequence within the same order of magnitude and the staircase-like succession between different magnitude intervals. DMSD's central objective can be summarized as: \[ \boxed{ \text{Theoretical Unboundedness} + \text{Operational Bounded Closure} + \text{Lazy Multiscale Expansion} } \] That is: the theoretical domain can extend indefinitely, but any individual computation handles only the actively specified maximum order of magnitude, local region and current resolution. --- # 1. Problem Background The sequence of natural numbers: \[ 1,2,3,4,5,\ldots \] has no theoretical upper bound. Yet every actual program, visualization, verification process and data structure can operate only with finite resources. The most direct approach usually specifies: \[ 1\le n\le N, \] and then expands all elements. When: \[ N=10^9,\;10^{12},\;10^{15} \] this representation of "domain size = number of physically expanded elements" quickly becomes impractical. DMSD adopts a different principle: > **Representing a huge, or even theoretically unbounded, mathematical domain does not mean that every element of the domain must be materialized simultaneously.** We represent scales first, then expand their interiors as needed. --- # 2. Decimal Scale Skeleton Let: \[ S_k=10^k, \qquad k\in\mathbb N_0. \] giving the scale sequence: \[ 1,\;10,\;100,\;1000,\ldots \] Formally define the order-of-magnitude level indexed by \(k\): \[ L_k = \{n\in\mathbb N\mid 10^k\le n<10^{k+1}\}. \] Thus: \[ L_0=[1,10), \] \[ L_1=[10,100), \] \[ L_2=[100,1000), \] and so on. In a visual description, this can be written as: ```text 1–10 10–100 100–1000 1000–10000 ... ``` Formal computation, however, uses half-open intervals to avoid duplicate boundaries. --- # 3. Magnitude Index and Local Position For any: \[ n\ge1, \] define the magnitude index: \[ \ell(n)=\lfloor\log_{10}n\rfloor. \] Then: \[ n\in L_{\ell(n)}. \] Next define the normalized position within a level: \[ \lambda_k(n) = \frac{n-10^k}{10^{k+1}-10^k}. \] Thus: \[ 0\le\lambda_k(n)<1. \] An arbitrary integer can be represented as: \[ \boxed{ n\mapsto(\ell(n),\lambda_{\ell(n)}(n)) } \] This allows local positions in different orders of magnitude to be mapped to the same normalized scale for comparison. --- # 4. First Perspective: Magnitude Pyramid The first main projection is called: \[ \boxed{ \text{Magnitude Pyramid View} } \] Its Chinese designation translates as: **Magnitude Pyramid View**. The essence of the pyramid is not "which end must physically be on top", but: \[ \boxed{ \text{Scale Hierarchy} + \text{Traversal Direction} } \] Two viewing directions must therefore be distinguished. --- # 5. Looking Down the Pyramid: Scale Expansion The first traversal: \[ L_0 \rightarrow L_1 \rightarrow L_2 \rightarrow \cdots \rightarrow L_K. \] Intuitively: ```text 1–10 ↓ 10–100 ↓ 100–1000 ↓ 1000–10000 ↓ ... ``` This represents: \[ \boxed{ \text{Small Scale} \rightarrow \text{Large Scale} } \] This paper calls it: **Scale Expansion View**. It is suited to studying: - How structure grows with the order of magnitude; - Whether a particular ratio is stable across scales; - Whether a phenomenon exists only at small scales; - Whether an asymptotic trend emerges; - When certain patterns appear or disappear. --- # 6. Looking Up the Pyramid: Scale Decomposition The second traversal first specifies a maximum scale: \[ L_K. \] For example: \[ K=9. \] Then it looks back in the opposite direction: \[ L_9 \rightarrow L_8 \rightarrow L_7 \rightarrow \cdots \rightarrow L_0. \] This does not mean "numbers becoming smaller in reverse", but: > **Choose a large global scale first, then look back at its composition and local structure on finer scales.** This paper calls it: **Scale Decomposition View**. It is suited to: - global-to-local； - coarse-to-fine； - Tracing large-scale anomalies back; - Increasing local resolution; - Returning from a macro summary to local blocks. --- # 7. Pyramid Center Coordinates Each \(L_k\) can have a local center defined as: \[ c_k = \frac{10^k+(10^{k+1}-1)}{2}. \] Define the displacement from the center: \[ \delta_k(n)=n-c_k. \] This can also be normalized: \[ \hat\delta_k(n) = \frac{n-c_k}{10^{k+1}-10^k}. \] The pyramid therefore shows more than just "which level"; it can also show: ```text scale + center + relative displacement ``` This allows subsequent property layers to compare structures relative to centers, boundaries and local positions across different orders of magnitude. --- # 8. Second Perspective: Serialized Staircase The second main projection is called: \[ \boxed{ \text{Serialized Staircase View} } \] Its Chinese designation translates as: **Serialized Staircase View**. Its central question is not the vertical relationship of scales, but: \[ \boxed{ \text{How does a sequence expand rightward within the same scale?} } \] The scales can be drawn as: ```text L0 ───────────────→ L1 ─────────────────────────→ L2 ───────────────────────────────→ L3 ─────────────────────────────────────→ ``` --- # 9. Coordinates Within a Staircase Level For: \[ n\in L_k, \] define the local linear position: \[ r_k(n) = n-10^k. \] Then: \[ r_k(n)\in[0,9\cdot10^k). \] The staircase view can therefore represent: \[ \boxed{ (k,r_k(n)) } \] where: - \(k\): order of magnitude; - \(r_k\): the rightward sequence position within that order of magnitude. --- # 10. The Pyramid and Staircase Share the Same Underlying Domain The two diagrams should not maintain two copies of the data. They should use: \[ \boxed{ \text{One Serialized Domain} \rightarrow \begin{cases} \text{Magnitude Pyramid Projection}\\ \text{Serialized Staircase Projection} \end{cases} } \] Thus: - Data is serialized only once; - Pyramid and Staircase are simply different observation projections; - Local refinement results can be synchronized between the two views. --- # 11. The Theoretically Unbounded Domain The scale sequence: \[ L_0,L_1,L_2,\ldots \] can theoretically extend indefinitely. It can therefore be denoted by: \[ \mathcal D_\infty. \] This "infinity" does not require the system to store infinitely many elements, but to store: ```text scale-generation rule scale-transition rule local-refinement rule ``` so that the system can respond to any finite-scale request. --- # 12. Operational Bounded Closure During actual operation, actively specify: \[ K_{\max}. \] The current runtime handles: \[ \mathcal D_{K_{\max}} = \bigcup_{k=0}^{K_{\max}}L_k. \] For example: \[ K_{\max}=12 \] means that the current global skeleton opens only the magnitude levels below \(10^{13}\). Formally: \[ \boxed{ \mathcal D_\infty = \lim_{K\to\infty}\mathcal D_K } \] Yet each computation handles only: \[ \boxed{ \mathcal D_K. } \] This paper calls it: \[ \boxed{ \text{Operational Bounded Closure} } \] That is: **Operational Bounded Closure**. --- # 13. Unbounded Theory Does Not Conflict with a Bounded Runtime DMSD's core is: \[ \boxed{ \text{Theoretical Unboundedness} + \text{Operational Bounded Closure} } \] The theoretical layer always permits generation of the next order of magnitude, as the unchanged source literal below says: ```text 永遠允許再生成下一個數量級 ``` The operational layer currently takes responsibility only within Kmax, as the unchanged source literal below says: ```text 目前只負責 Kmax 以內 ``` This makes "infinitely many orders of magnitude" a generative capacity, not a quantity of data to be stored all at once. --- # 14. Global Skeleton First DMSD should not begin by expanding: \[ 1,2,3,\ldots,10^K. \] Instead, it should first establish only: ```text L0 L1 L2 ... LK ``` That is: \[ \boxed{ \text{Global Scale Skeleton} } \] If only scale-level nodes are created, their number is approximately: \[ K+1. \] The cost of the global view can therefore be approximated by: \[ O(K) \] rather than: \[ O(10^K). \] --- # 15. Deferred Resolution Expansion Each scale node initially stores only a summary. For example: ```yaml scale_block: level: k start: 10^k end: 10^(k+1)-1 element_count: 9*10^k resolution: unopened summary_state: available ``` Only when: - A user zooms; - A probe requests it; - A region needs analysis; - A statistic needs finer resolution; is local refinement performed. --- # 16. Block Refinement Let: \[ B \] be a block. Define the refinement operator: \[ \mathcal R(B) = (B_1,\ldots,B_m). \] Thus: \[ B \rightarrow B_i \rightarrow B_{ij} \rightarrow B_{ijk} \rightarrow\cdots \] can continue increasing resolution. This strategy is called: \[ \boxed{ \text{Lazy Multiscale Expansion} } \] or: \[ \boxed{ \text{Progressive Resolution Expansion} } \] --- # 17. Example: Expand Only the Required Region Suppose the global skeleton has been set up to: \[ 10^{12}. \] The system does not need to draw \(10^{12}\) elements. If the user views only: \[ [10^8,10^9), \] then only: \[ L_8 \] is refined further. If the interest subsequently narrows to: \[ [4\times10^8,5\times10^8), \] only this sub-block is expanded. Thus: \[ \boxed{ \text{Global Represented Domain Size} \neq \text{Actually Computed Element Count} } \] --- # 18. Resolution Parameter Let: \[ \rho \] denote the current resolution. The same block: \[ B \] can have: \[ B^{(\rho_0)}, B^{(\rho_1)}, B^{(\rho_2)},\ldots \] A coarse resolution stores only a summary; finer resolution gradually adds: - Sub-blocks; - Elements; - property； - local statistics； - certificates。 --- # 19. Computational Cost Model Traditional naive expansion up to: \[ 10^K \] may require approximately: \[ O(10^K) \] element-level processing. DMSD aims to express the cost instead as: \[ \boxed{ C=C(K,\rho,\Omega) } \] where: - \(K\): maximum order of magnitude; - \(\rho\): required resolution; - \(\Omega\): the region actually expanded. Ideally: \[ C(K,\rho,\Omega) \ll 10^K \] provided that: \[ |\Omega| \ll 10^K. \] --- # 20. Multiscale Block Object An actual block can be provisionally formalized as: \[ B = (k,a,b,\rho,S,C,H), \] where: - \(k\): scale level; - \([a,b)\): actual interval; - \(\rho\): resolution; - \(S\): summary state; - \(C\): computation / certificate state; - \(H\): refinement history / provenance. This allows DMSD to be implemented directly as runtime objects, not merely as a visual model. --- # 21. Lazy Rendering of Pyramid and Staircase Initially, the Pyramid needs to draw only: ```text L0 L1 L2 ... LK ``` Initially, the Staircase needs to draw only: ```text L0 → L1 → L2 → ... LK → ``` Actual elements are expanded only after: ```text selection zoom probe request analysis ``` occurs. The UI can therefore be separated from the computational backend: \[ \boxed{ \text{Global Skeleton Rendering} + \text{Local Computational Expansion} } \] --- # 22. Traversal as a Model Parameter DMSD has at least three traversals: \[ \tau_{\downarrow} \] represents: \[ L_0\to L_1\to\cdots \] that is, smaller to larger scales; \[ \tau_{\uparrow} \] represents: \[ L_K\to L_{K-1}\to\cdots \] that is, from a large scale to finer scales; and: \[ \tau_{\rightarrow} \] represents rightward sequence expansion within the same scale. DMSD can therefore be viewed as a mathematical observation space of: \[ \boxed{ \text{Scale} \times \text{Local Position} \times \text{Traversal} } \] these components. --- # 23. Separate the Domain from Property Layers Initially, the DMSD Core should not directly contain: ```text prime composite square odd even mod residue ``` A more appropriate form is: \[ \boxed{ \text{DMSD Core} + \text{Property Layers} } \] The underlying layer is responsible only for: - Scales; - Intervals; - Resolution; - refinement； - serialization； - traversal。 Mathematical properties are layered on afterward. --- # 24. Property Layer For any property: \[ Q(n), \] define at level \(k\): \[ Q_k = \{n\in L_k:Q(n)\}. \] and the within-level density: \[ d_k(Q) = \frac{|Q_k|}{|L_k|}. \] It can also be projected onto: \[ \lambda_k \] to compare normalized distributions at different orders of magnitude. --- # 25. Why Not Introduce Primes Yet The first phase should verify: > Whether DMSD itself is a stable, effective, scalable mathematical domain that can be expanded lazily. Introduce simple properties first: - odd/even； - mod 3； - mod 5； - squares； - obvious composites。 If even these cannot produce consistent, replayable multiscale behavior in Pyramid / Staircase, there is no need to introduce a prime layer immediately. --- # 26. The Prime Layer Should Be a Later Module Only after the DMSD Core is stable should one introduce: \[ \boxed{ \mathcal P_{\mathrm{prime}} } \] and study: - scale-wise prime density； - normalized local position； - center deviation； - boundary effects； - staircase gap structure； - scale-to-scale transfer； - cross-base artifacts。 This avoids letting prime conjectures dominate the underlying model from the outset again. --- # 27. Decimal Is Not Mathematical Ontology DMSD v0.1 uses decimal because it is: - Intuitive for humans; - Natural for orders of magnitude; - Friendly to visualization; - Easy to engineer; - Compatible with existing data representations. Yet: \[ \boxed{ \text{Decimal} \neq \text{Mathematical Ontology} } \] DMSD's true core is: \[ \boxed{ \text{Multiscale Serializable Domain} } \] Decimal is merely the first scale grammar. --- # 28. Representation Artifact Audit Duty Any pattern appearing only in base-10 must undergo cross-representation validation with: - base 2； - base 8； - base 16； - adaptive scale； and other representations. If the pattern disappears after changing base, it should be labelled: \[ \boxed{ \text{Representation Artifact} } \] rather than an ontological mathematical structure. --- # 29. Resolution Artifact Audit Duty A pattern seen at coarse resolution likewise cannot be directly treated as local reality. Every summary state must carry: ```text resolution coverage aggregation rule ``` If a coarse-view pattern disappears after finer refinement, it should be labelled: \[ \boxed{ \text{Resolution Artifact} } \] --- # 30. Bounded Extrapolation Duty If the current expansion reaches only: \[ K_{\max}, \] then every empirical conclusion must explicitly state: \[ \boxed{ \text{validated only up to }K_{\max} } \] A result on: \[ \mathcal D_K \] cannot be directly promoted to a global proposition on: \[ \mathcal D_\infty \] that domain. --- # 31. Initial Form of DMSD DMSD is provisionally defined as: \[ \mathfrak D_{\mathrm{DMSD}} = ( K, \mathcal L, \mathcal R, \mathcal V, \mathcal S, \mathcal C, \mathcal H ), \] where: - \(K\): current maximum scale; - \(\mathcal L\): set of scale levels; - \(\mathcal R\): refinement rules; - \(\mathcal V\): visual projection rules; - \(\mathcal S\): summary states; - \(\mathcal C\): computation / certificate states; - \(\mathcal H\): refinement history. --- # 32. Relationship to Serializable Infinite Mathematical Domains DMSD continues the central principle of serializable infinite mathematical domains: > **Infinity need not be stored all at once; it suffices to preserve a generative rule that can keep responding to requests for any finite precision and finite scale.** Thus: \[ \boxed{ \text{Infinite Domain} = \text{Finite Scale Rule} + \text{Indefinite Refinement} } \] --- # 33. Foundational Design Principles DMSD v0.1 provisionally adopts the following principles. ### P1 — Scale First Serialize scales first, then elements. ### P2 — Global Skeleton First Build the global skeleton first, then expand locally. ### P3 — Lazy Resolution Generate resolution on demand. ### P4 — Traversal Explicitness The meanings of downward, upward and rightward traversal must be kept separate. ### P5 — Operational Bounded Closure Every runtime has an explicit finite boundary. ### P6 — Theoretical Unboundedness A finite runtime does not prevent the theoretical domain from extending further. ### P7 — Domain / Property Separation Separate the underlying scale domain from mathematical property layers. ### P8 — Representation Audit Decimal phenomena must not be directly treated as mathematical ontology. ### P9 — Resolution Audit Coarse-resolution visuals must not be directly promoted to fine-scale theorems. --- # 34. Phase 1 Implementation Objectives The first phase implements only the core domain: ```text DMSD Core ├─ Decimal scale hierarchy ├─ Magnitude Pyramid View ├─ Serialized Staircase View ├─ downward traversal ├─ upward traversal ├─ rightward traversal ├─ block selection ├─ lazy refinement ├─ local zoom └─ summary/provenance state ``` It does not handle primes. --- # 35. Phase 2 Implementation Objectives Introduce simple property layers: ```text parity mod 3 mod 5 squares simple composites ``` Test: - Whether Pyramid / Staircase are synchronized; - Whether summaries can be refined correctly; - Whether coarse / fine resolutions are consistent; - Whether traversal changes observation without changing the underlying data. --- # 36. Phase 3 Implementation Objectives Introduce the Prime Layer: ```text prime density prime local position prime center deviation prime gaps cross-scale normalization boundary effects ``` and retain cross-base auditing. --- # 37. Future Extensions DMSD could subsequently extend to: ```text Decimal DMSD → Base-independent Multiscale Serializable Domain → Adaptive Multiscale Serializable Domain → General Serializable Mathematical Domain Runtime ``` Ultimately, decimal may be merely a frontend scale grammar. --- # 38. Central Proposition This paper proposes the following foundational proposition: > **A theoretically unbounded discrete mathematical domain can first be serialized as a scale hierarchy without expanding all its elements at once; actual computation needs to form a bounded closure only for a specified maximum scale, specified local region and specified resolution, and can increase local resolution through lazy refinement.** Formally: \[ \boxed{ \mathcal D_\infty = \lim_{K\to\infty}\mathcal D_K } \] while any individual computation acts only on: \[ \boxed{ (\mathcal D_K,\Omega,\rho). } \] --- # 39. Shortest Formulation Condensed into a single sentence: \[ \boxed{ \text{First serialize the unbounded numerical domain into scales; compute only the resolution currently needed.} } \] Including the dual perspectives: \[ \boxed{ \text{The pyramid shows scales, the staircase sequences; both share the same lazily expandable mathematical domain.} } \] --- # 40. Conclusion DMSD does not attempt to draw or compute all natural numbers at once. What it proposes is: \[ \boxed{ \text{The unbounded domain serializes scales first, a finite runtime then expands content locally.} } \] Its core consists of four parts: \[ \boxed{ \text{Theoretical Unboundedness} } \] \[ \boxed{ \text{Operational Bounded Closure} } \] \[ \boxed{ \text{Lazy Multiscale Expansion} } \] \[ \boxed{ \text{Pyramid / Staircase Dual Projection} } \] Thus, when facing extremely large orders of magnitude in the future, "how far can be represented" need not be tied to "how much must be computed now". The global domain can first exist as: ```text scale skeleton ``` while the local region is acted on only when genuinely needed: ```text expand refine compute certify ``` This makes decimal orders of magnitude more than a visual convenience: they become the first implementable multiscale serializable domain. --- ## Status ```text DMSD v0.1 Foundational Methodology: COMPLETE Next: Phase 1 — Formal Data Model Phase 1 — Pyramid / Staircase Visualization Prototype Phase 1 — Lazy Resolution Runtime ```