docs: the 12 duplicates deleted; README rewritten to the system as it is
Captain Bob's rulings, 2026-10-14: "delete" -- the duplicates listed in DELETE-CANDIDATES.md are removed (the list stays as the record; the formal tier's provenance comments repointed at the maintained copies) -- and "rewrite" the README: v2.1.0, the Tripod as Hera/Artemis/Hestia, kernel-Hermes, identities on thumbdrives, the corrected ACL overhead, 1052-test POST and the current parity line, keyboards and storage, board images carrying both systems and how to switch, and docs/README.md as the way in. The book is left as it is, to be reworked later. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
rajames
co-authored by
Claude Opus 5.5
Claude Opus 5.5
parent
776c89457e
commit
f8fbc37698
@@ -1,393 +0,0 @@
|
||||
<!-- Moved from docs/reference/word-acl/DESIGN.md to docs/working/architecture/03-architecture/word-acl/DESIGN.md on 2026-06-16 (docs reorg Phase 2) -->
|
||||
# Word-Level ACL System
|
||||
|
||||
**Status:** Implemented through Phase 6 — Phase 7 (LithosAnanke parity) remaining
|
||||
**Target branch:** `master` complete; `lithosananke` parity next
|
||||
**Implementation files:** `capsules/ACL.4th`, `capsules/zuse.4th`, `src/word_source/acl_words.c`, `src/test_runner/modules/acl_words_test.c`
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
### Overview
|
||||
|
||||
A word-level access control system for StarForth VMs, implemented as a
|
||||
combination of a thin C infrastructure layer and a pure-FORTH policy capsule
|
||||
(`ACL.4th`). The C layer provides four `DictEntry` fields for the hot path
|
||||
(TTL counter + allow bit + mode + pin). All policy, all adaptive logic, all
|
||||
inheritance rules live as colon definitions in `ACL.4th`. A bootstrap
|
||||
superuser (`zuse.4th`) provides the sole authenticated escalation path.
|
||||
|
||||
---
|
||||
|
||||
### ACL Disposition — Three States
|
||||
|
||||
Each word in the dictionary has one of three enforcement dispositions:
|
||||
|
||||
| State | Behavior |
|
||||
|-------|---------|
|
||||
| `STRICT` | ACL re-checked on every execution |
|
||||
| `TTL` | ACL cached; re-checked only when TTL counter reaches zero |
|
||||
| `PINNED` | Current mode and decision frozen permanently; one-way ratchet |
|
||||
|
||||
---
|
||||
|
||||
### TTL — Statistically Adaptive
|
||||
|
||||
The TTL is not a fixed value. It is derived and continuously updated from
|
||||
the existing SSM execution physics:
|
||||
|
||||
- **Heat** (`execution_heat`): hotter words earn longer TTLs; check cost
|
||||
amortized over more executions
|
||||
- **Rolling window**: sudden shift in caller pattern or access rate causes
|
||||
TTL to shrink aggressively
|
||||
- **Decay**: quiescent words pull their TTL back down so the next burst
|
||||
re-validates early
|
||||
- **Inference engine** (L5/L6): detects oscillating TTL and stabilizes it —
|
||||
same CV threshold logic already used for window-width inference
|
||||
|
||||
`PINNED` is the asymptote: the adaptive process converges, you thumbtack
|
||||
it, and the accumulator freezes permanently.
|
||||
|
||||
A FORTH security word selects enforcement mode per word:
|
||||
|
||||
```forth
|
||||
' MY-WORD ACL-STRICT \ check every execution
|
||||
' MY-WORD ACL-TTL-MODE \ use adaptive TTL
|
||||
' MY-WORD ACL-PIN \ freeze — mode and decision immutable forever
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### The Thumbtack / Pin Flag
|
||||
|
||||
`ACL-PIN ( xt -- )` is a one-way ratchet:
|
||||
|
||||
- Transitions: `STRICT → PINNED` or `TTL → PINNED` — never back
|
||||
- Once pinned, `acl_mode` and `acl_ttl` are immutable for that VM context
|
||||
- Any attempt to change a pinned word's ACL is silently ignored (or errors,
|
||||
depending on policy)
|
||||
- Kernel primitive words (`BIRTH`, `EXEC`, `BYE`, etc.) are pinned by Mama
|
||||
at boot before the first `BIRTH` fires
|
||||
|
||||
---
|
||||
|
||||
### Inheritance at Birth
|
||||
|
||||
When a child VM is born:
|
||||
|
||||
```
|
||||
acl_mode = parent->acl_mode \ policy propagates (STRICT or TTL)
|
||||
acl_pinned = 0 \ always clear — child owns its own lock
|
||||
acl_ttl = default \ reset; child has no execution history
|
||||
acl_decision = ALLOW \ re-evaluated on first access
|
||||
```
|
||||
|
||||
Key properties:
|
||||
|
||||
- **Pin is contextual, not viral.** A parent's pinned words do not force
|
||||
the child to be pinned. The child inherits the mode as a starting point
|
||||
and can tighten, relax, or re-pin freely.
|
||||
- **Security lattice flows downward at birth only.** After birth, each VM's
|
||||
ACL state is independent. A compromised child cannot bootstrap its way
|
||||
back to Mama's pinned ACLs.
|
||||
|
||||
---
|
||||
|
||||
### Interpreter Hook — Two-Level Check
|
||||
|
||||
The C interpreter reads only two fields per `DictEntry`:
|
||||
|
||||
```c
|
||||
if (vm->emergency_console) goto execute; /* 100% bypass — physical access */
|
||||
if (entry->acl_ttl-- > 0) goto execute; /* TTL good — single decrement */
|
||||
acl_recheck(vm, entry); /* TTL=0: call FORTH ACL-RECHECK */
|
||||
if (!entry->acl_allow) goto reject;
|
||||
```
|
||||
|
||||
**Hot path cost:** one decrement and a branch — essentially free.
|
||||
**Cold path:** calls `ACL-RECHECK` in `ACL.4th`, which recomputes the
|
||||
adaptive TTL, updates `acl_allow`, and resets the counter. The C side
|
||||
never reasons about policy; it only reads the result.
|
||||
|
||||
---
|
||||
|
||||
### Two-Console Architecture
|
||||
|
||||
Two permanent, independent console layers exist at all times:
|
||||
|
||||
#### 1. Emergency Console (always present)
|
||||
|
||||
- `emergency_console` (`uint8_t`) flag in `VM` struct — C-only write; no
|
||||
FORTH word sets it
|
||||
- Checked first in the interpreter hot path — 100% ACL bypass
|
||||
- `acl_recheck()` uses save/restore around it for re-entrancy protection
|
||||
- `EMERGENCY_CONSOLE_ENABLED` Makefile build flag (default=1): when set to
|
||||
0, strips interactive fallthrough; `vm_fault_handler()` weak symbol is
|
||||
called instead (override for hardware reset, watchdog, debug probe)
|
||||
- `BYE` returns to the emergency console
|
||||
- Only `panic` kills the VM
|
||||
- Prompt: `ok>`
|
||||
|
||||
#### 2. Zuse Console (omnipresent, awaiting authentication)
|
||||
|
||||
- `zuse_session` (`uint8_t`) flag in `VM` struct — C-only write; no FORTH
|
||||
word sets it
|
||||
- Prompt: `zuse)ok>`
|
||||
- Full ACL bypass when a Zuse session is active
|
||||
- Completely independent of `emergency_console` — setting one does not
|
||||
affect the other
|
||||
|
||||
---
|
||||
|
||||
### Superuser: Zuse
|
||||
|
||||
Named for Konrad Zuse, pioneer of programmable computers. Zuse is the
|
||||
bootstrap superuser: the sole entity that can own the zuse console and mint
|
||||
user credentials.
|
||||
|
||||
- Defined in `capsules/zuse.4th`, loaded by `ACL.4th` at capsule boot
|
||||
- Software-only for now (no thumbdrive); `zuse.4th` is a capsule citizen
|
||||
from day one
|
||||
- Zuse's words are pinned by `ACL-ZUSE-BOOT` at load time
|
||||
- `ACL-BOOT` is called first, then `S" zuse.4th" EXEC` — both from within
|
||||
`ACL.4th` itself (Block 2067)
|
||||
- Future: replace with thumbdrive PKI (Ed25519 challenge-response);
|
||||
`zuse.4th` becomes the bootstrapper that validates the physical drive
|
||||
|
||||
---
|
||||
|
||||
### CA Root
|
||||
|
||||
- Embedded in `ACL.4th` (Block 2066) as constants `ACL-CA-KEY-LO` /
|
||||
`ACL-CA-KEY-HI`
|
||||
- Capsule hash = root-of-trust fingerprint: any CA key change changes the
|
||||
capsule hash and the birth protocol detects tampering
|
||||
- Placeholder (zeros) until `tools/mkcapsule` embeds the real Ed25519 key
|
||||
at build time
|
||||
|
||||
---
|
||||
|
||||
### Security Model / No-Security Condition
|
||||
|
||||
Security is opt-in via `init.4th`. The toggle is one commented-out line:
|
||||
|
||||
```forth
|
||||
\ S" ACL.4th" EXEC
|
||||
```
|
||||
|
||||
| `ACL.4th` | `zuse.4th` | Result |
|
||||
|-----------|------------|--------|
|
||||
| absent | absent | No security — open dev mode |
|
||||
| present | absent | ACL enforced; emergency REPL locked until Zuse provisioned |
|
||||
| present | present | Full lockdown; Zuse owns the zuse console |
|
||||
|
||||
Uncomment the line in `init.4th` to enable full lockdown. Leave it
|
||||
commented out for development builds.
|
||||
|
||||
---
|
||||
|
||||
### Self-Activating Capsule
|
||||
|
||||
`ACL.4th` is self-activating — `init.4th` only needs one line:
|
||||
|
||||
```forth
|
||||
S" ACL.4th" EXEC
|
||||
```
|
||||
|
||||
Internal structure of `ACL.4th`:
|
||||
- **Block 2066**: CA root placeholder constants (`ACL-CA-KEY-LO` /
|
||||
`ACL-CA-KEY-HI`)
|
||||
- **Block 2067**: Calls `ACL-BOOT` then `S" zuse.4th" EXEC`
|
||||
|
||||
`ACL-BOOT` stamps default ACL entries on all existing dictionary words.
|
||||
After it runs, every subsequent `:` definition gets an ACL entry via the
|
||||
defining-word hook. No word can exist without an ACL entry.
|
||||
|
||||
---
|
||||
|
||||
### Emergency Console — 100% Bypass
|
||||
|
||||
`vm->emergency_console` is set by the C layer when the physical `ok>` REPL
|
||||
is active. It is checked first, before any ACL table lookup. Physical
|
||||
presence always wins. The emergency console is never subject to ACL
|
||||
constraints regardless of what `ACL.4th` defines.
|
||||
|
||||
The `EMERGENCY_CONSOLE_ENABLED=0` build flag strips the interactive
|
||||
fallthrough for production or embedded builds, routing faults to
|
||||
`vm_fault_handler()` instead.
|
||||
|
||||
---
|
||||
|
||||
### ACL.4th — Pure FORTH Implementation
|
||||
|
||||
The ACL table is a `CREATE`d FORTH array indexed by execution token (XT).
|
||||
`'` (tick) gives the XT of any word; XT is just a cell value usable as a
|
||||
table key.
|
||||
|
||||
Core words:
|
||||
|
||||
| Word | Stack | Description |
|
||||
|------|-------|-------------|
|
||||
| `ACL-ENTRY` | `( xt -- addr )` | O(1) table lookup by XT |
|
||||
| `ACL-MODE@` | `( xt -- mode )` | read enforcement mode |
|
||||
| `ACL-MODE!` | `( mode xt -- )` | set mode (no-op if pinned) |
|
||||
| `ACL-PINNED?` | `( xt -- flag )` | test pin bit |
|
||||
| `ACL-PIN` | `( xt -- )` | set pin — one-way, irreversible |
|
||||
| `ACL-STRICT` | `( xt -- )` | set STRICT mode (no-op if pinned) |
|
||||
| `ACL-TTL-MODE` | `( xt -- )` | set TTL mode (no-op if pinned) |
|
||||
| `ACL-TTL@` | `( xt -- n )` | read current TTL counter |
|
||||
| `ACL-TTL!` | `( n xt -- )` | write TTL counter |
|
||||
| `ACL-ALLOW@` | `( xt -- flag )` | read cached allow/deny decision |
|
||||
| `ACL-ALLOW!` | `( flag xt -- )` | write allow/deny decision |
|
||||
| `ACL-INHERIT` | `( src dst -- )` | birth inheritance: copy mode, clear pin, reset ttl+decision |
|
||||
| `ACL-RECHECK` | `( xt -- )` | adaptive TTL recomputation; updates allow + new TTL |
|
||||
| `ACL-INIT-PRIMITIVES` | `( -- )` | bulk-initialize ACL entries for all existing dictionary words |
|
||||
|
||||
Example pin at boot in `init.4th`:
|
||||
|
||||
```forth
|
||||
' BIRTH ACL-STRICT ' BIRTH ACL-PIN
|
||||
' EXEC ACL-STRICT ' EXEC ACL-PIN
|
||||
' BYE ACL-STRICT ' BYE ACL-PIN
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Bootstrap Sequence
|
||||
|
||||
```forth
|
||||
\ In init.4th (one line, opt-in toggle — uncomment to enable):
|
||||
S" ACL.4th" EXEC \ self-activating: calls ACL-BOOT then loads zuse.4th
|
||||
|
||||
\ ACL.4th Block 2067 does internally:
|
||||
ACL-BOOT \ stamp default ACLs on all existing words
|
||||
S" zuse.4th" EXEC \ load and pin Zuse's words
|
||||
|
||||
\ Subsequent capsule loads (e.g. doe.4th) get ACL entries via : hook
|
||||
S" doe.4th" EXEC
|
||||
```
|
||||
|
||||
Every `:` definition after `ACL-BOOT` runs creates its own ACL entry at
|
||||
definition time via a hook in the defining word. No word is ever born
|
||||
without an ACL entry.
|
||||
|
||||
---
|
||||
|
||||
### Capsule Namespace
|
||||
|
||||
| File | Role |
|
||||
|------|------|
|
||||
| `init.4th` | Mama VM personality (default); contains opt-in ACL toggle |
|
||||
| `init-*.4th` | Alternate personalities |
|
||||
| `doe.4th` | DoE experiment harness |
|
||||
| `ACL.4th` | Word-level ACL subsystem — self-activating; loads `zuse.4th` |
|
||||
| `zuse.4th` | Bootstrap superuser personality; words pinned by `ACL-ZUSE-BOOT` |
|
||||
| `std-blob.4th` | Standard library layer (future) |
|
||||
|
||||
---
|
||||
|
||||
## Implementation Punch List
|
||||
|
||||
### Phase 1 — C Infrastructure (`master`) ✅ COMPLETE
|
||||
|
||||
- [x] Add `acl_ttl` (`uint32_t`) to `DictEntry` in `include/vm.h`
|
||||
- [x] Add `acl_allow` (`uint8_t`) to `DictEntry`
|
||||
- [x] Add `acl_mode` (`uint8_t`: STRICT=0 / TTL=1) to `DictEntry`
|
||||
- [x] Add `acl_pinned` (`uint8_t`) to `DictEntry`
|
||||
- [x] Default-initialize all four fields in `word_register()`:
|
||||
`ttl=ACL_OPEN, allow=1, mode=TTL, pinned=0`
|
||||
- [x] Add `emergency_console` (`uint8_t`) flag to `VM` struct
|
||||
- [x] Add `zuse_session` (`uint8_t`) flag to `VM` struct
|
||||
- [x] Insert two-level ACL check into interpreter loop in `vm.c`
|
||||
- [x] Implement `acl_recheck()` in `vm.c` — calls FORTH `ACL-RECHECK` when
|
||||
TTL=0; save/restore `emergency_console` for re-entrancy protection
|
||||
- [x] Add `:` definition hook to create ACL entry for each newly defined word
|
||||
|
||||
### Phase 2 — C Primitive Words + `ACL.4th` Capsule (`master`) ✅ COMPLETE
|
||||
|
||||
- [x] 12 C primitive words in `src/word_source/acl_words.c`
|
||||
- [x] `CREATE ACL-TABLE` sized to max dictionary entries
|
||||
- [x] `ACL-ENTRY ( xt -- addr )` — XT-indexed O(1) lookup
|
||||
- [x] Field accessors: `ACL-MODE@`, `ACL-MODE!`, `ACL-PINNED?`,
|
||||
`ACL-TTL@`, `ACL-TTL!`, `ACL-ALLOW@`, `ACL-ALLOW!`
|
||||
- [x] `ACL-PIN ( xt -- )` — one-way ratchet; no-op if already pinned
|
||||
- [x] `ACL-STRICT ( xt -- )` — set STRICT mode; no-op if pinned
|
||||
- [x] `ACL-TTL-MODE ( xt -- )` — set TTL mode; no-op if pinned
|
||||
- [x] `ACL-INHERIT ( src-xt dst-xt -- )` — copy mode, clear pin,
|
||||
reset ttl+decision
|
||||
- [x] `ACL-RECHECK ( xt -- )` — recompute adaptive TTL from heat and rolling
|
||||
window; update `acl_allow` and reset counter
|
||||
- [x] `ACL-INIT-PRIMITIVES` — walk dictionary, create default entry per word
|
||||
- [x] Pin privileged words: `BIRTH`, `EXEC`, `BYE`, and other Mama-only words
|
||||
|
||||
### Phase 3 — `capsules/ACL.4th` Self-Activating Capsule (`master`) ✅ COMPLETE
|
||||
|
||||
- [x] `ACL.4th` is self-activating: Block 2067 calls `ACL-BOOT` then
|
||||
`S" zuse.4th" EXEC`
|
||||
- [x] Block 2066: CA root placeholder constants (`ACL-CA-KEY-LO` /
|
||||
`ACL-CA-KEY-HI`)
|
||||
- [x] `ACL-BOOT` stamps default ACL entries on all existing dictionary words
|
||||
- [x] `capsules/zuse.4th` loaded at end of `ACL.4th` capsule
|
||||
- [x] Zuse's words pinned by `ACL-ZUSE-BOOT` at load time
|
||||
|
||||
### Phase 4 — `init.4th` Opt-In Toggle (`master`) ✅ COMPLETE
|
||||
|
||||
- [x] `init.4th` has one commented-out line as the opt-in toggle:
|
||||
`\ S" ACL.4th" EXEC`
|
||||
- [x] Uncomment to enable full lockdown; leave commented for dev/open mode
|
||||
- [x] No other changes to `init.4th` required — `ACL.4th` is self-contained
|
||||
|
||||
### Phase 5 — POST Tests (`master`) ✅ COMPLETE
|
||||
|
||||
POST tests implemented in `src/test_runner/modules/acl_words_test.c`,
|
||||
registered in `src/test_runner/test_runner.c`. 800/800 passing.
|
||||
|
||||
- [x] POST test: `ACL-PIN` is one-way — mode cannot change after pin set
|
||||
- [x] POST test: inheritance — child entry has mode copied, pin cleared,
|
||||
ttl and decision reset
|
||||
- [x] POST test: emergency console bypass — `emergency_console=1` skips
|
||||
ACL check entirely
|
||||
- [x] POST test: STRICT mode — ACL re-evaluated on every execution
|
||||
- [x] POST test: TTL hot path — TTL > 0 bypasses re-evaluation
|
||||
- [x] POST test: adaptive accumulator — heat increase produces TTL increase
|
||||
- [x] POST test: privileged words pinned at boot remain pinned after
|
||||
`ACL-INIT-PRIMITIVES`
|
||||
|
||||
### Phase 6 — Isabelle/HOL Formal Verification (`master`) ✅ COMPLETE
|
||||
|
||||
Five `.thy` files in `proof/` alongside existing VM proofs:
|
||||
|
||||
- [x] `ACL_Pin_Monotone.thy` — pin bit is set-only; no operation clears it
|
||||
once set
|
||||
- [x] `ACL_Inherit_Clears_Pin.thy` — `ACL-INHERIT` always produces an entry
|
||||
with `acl_pinned = 0` regardless of source entry state
|
||||
- [x] `ACL_TTL_Bounded.thy` — TTL counter is bounded above by
|
||||
`ACL-TTL-COMPUTE` output; cannot grow unboundedly
|
||||
- [x] `ACL_Emergency_Bypass.thy` — when `emergency_console = 1` the
|
||||
allow/deny decision is never consulted
|
||||
- [x] `ACL_No_Escalation.thy` — a child VM cannot produce a pinned entry
|
||||
with higher privilege than its inherited mode
|
||||
|
||||
### Phase 7 — LithosAnanke Parity (REMAINING)
|
||||
|
||||
- [ ] Merge / port ACL subsystem to `lithosananke` branch
|
||||
- [ ] Verify `ACL.4th` loads cleanly in kernel context (freestanding)
|
||||
- [ ] `ACL-BOOT` runs at kernel boot before first `BIRTH`
|
||||
- [ ] `vm->emergency_console` wired to kernel REPL active flag
|
||||
- [ ] `vm->zuse_session` wired to kernel Zuse console authentication path
|
||||
- [ ] Three-arch acceptance: amd64, aarch64, riscv64 boot to `ok>` with ACL
|
||||
active and no regressions
|
||||
- [ ] Commit acceptance logs
|
||||
|
||||
### Phase 8 — PKI / Thumbdrive Authentication (FUTURE)
|
||||
|
||||
- [ ] Ed25519 challenge-response authentication for Zuse thumbdrive
|
||||
- [ ] `tools/mkcapsule` embeds real Ed25519 CA key into `ACL.4th` Block 2066
|
||||
at build time (replacing zero placeholder)
|
||||
- [ ] User minting: admin creates thumbdrive with CA-signed certificate + home
|
||||
block image
|
||||
- [ ] Lose the drive → admin mints a new one; no software recovery path by
|
||||
design
|
||||
- [ ] `zuse.4th` becomes the bootstrapper that validates the physical drive
|
||||
before granting Zuse session access
|
||||
-345
@@ -1,345 +0,0 @@
|
||||
================================================================================
|
||||
FORMAL VERIFICATION CLAIMS: PHYSICS-DRIVEN SELF-ADAPTIVE FORTH-79 VM
|
||||
================================================================================
|
||||
|
||||
For use in peer review submissions and formal verification papers.
|
||||
|
||||
These claims are supported by the 90-run validation experiment and are
|
||||
defensible against reviewer scrutiny.
|
||||
|
||||
================================================================================
|
||||
CLAIM 1: ALGORITHMIC DETERMINISM
|
||||
================================================================================
|
||||
|
||||
STATEMENT:
|
||||
"The physics-driven adaptation model produces deterministic behavior,
|
||||
enabling formal verification of the system's correctness."
|
||||
|
||||
SUPPORTING EVIDENCE:
|
||||
- Cache hit rates: 17.39% ± 0.00% (zero variance across 30 runs)
|
||||
- Coefficient of variation (CV): 0% for all cache metrics
|
||||
- Runtime behavior: Perfectly reproducible post-warmup
|
||||
|
||||
FORMAL DEFINITION:
|
||||
For all valid programs P and configurations C:
|
||||
execute(P, C, t₁) ≡ execute(P, C, t₂)
|
||||
|
||||
where both t₁ and t₂ are post-warmup (after 15+ runs)
|
||||
|
||||
DEFENSE AGAINST REVIEWERS:
|
||||
Q: "Isn't the variation just measurement noise?"
|
||||
A: "We measured two types of variance:
|
||||
(1) Cache hit rates: 0% internal variance
|
||||
(2) Runtime: 60-70% variance (traced to OS scheduling, not algorithm)
|
||||
|
||||
The separation proves the algorithm is deterministic."
|
||||
|
||||
Q: "How do you know cache hits are truly consistent?"
|
||||
A: "All 30 runs per configuration report identical hit rates (17.39%).
|
||||
This is empirically proven, not assumed. Reproducible raw data available."
|
||||
|
||||
METRIC FOR PAPER: "Algorithmic Consistency Guarantee: σ_cache = 0%"
|
||||
|
||||
================================================================================
|
||||
CLAIM 2: ADAPTIVE CONVERGENCE
|
||||
================================================================================
|
||||
|
||||
STATEMENT:
|
||||
"The system demonstrates measurable convergence toward optimal configuration,
|
||||
proving the adaptation mechanism is functional and effective."
|
||||
|
||||
SUPPORTING EVIDENCE:
|
||||
- C_FULL (adaptive): -25.4% improvement (early vs. late runs)
|
||||
- B_CACHE (moderate): +0.5% stable (already optimal)
|
||||
- A_BASELINE (non-adaptive): +6.4% degradation (no optimization possible)
|
||||
|
||||
FORMAL DEFINITION:
|
||||
Define: OptimalityGap(t) = P_optimal - P_actual(t)
|
||||
|
||||
Convergence proof:
|
||||
OptimalityGap(t₁₆₊) < OptimalityGap(t₁₋₁₅)
|
||||
|
||||
Measured: 7.61 ms (late) < 10.20 ms (early)
|
||||
Gap reduction: 2.59 ms (25.4% improvement)
|
||||
|
||||
DEFENSE AGAINST REVIEWERS:
|
||||
Q: "Isn't this just JIT warmup, not adaptive optimization?"
|
||||
A: "Three points:
|
||||
(1) Your warmup is already implemented (PRE/POST phases)
|
||||
(2) A_BASELINE shows NO improvement despite same warmup
|
||||
(3) B_CACHE shows minimal improvement
|
||||
(4) ONLY C_FULL (with adaptation) shows 25% convergence
|
||||
|
||||
This proves improvement is configuration-dependent."
|
||||
|
||||
Q: "Why does A_BASELINE get slower?"
|
||||
A: "Perfect! This validates our hypothesis:
|
||||
- A_BASELINE has no adaptation mechanism → no improvement possible
|
||||
- Slight degradation (+6.4%) is expected under sustained load
|
||||
- This non-response proves the system is responding to its model, not random"
|
||||
|
||||
Q: "Could this be better explained by cache warming?"
|
||||
A: "Cache warming is included in PRE phase (your current implementation).
|
||||
The C_FULL improvement occurs in LATE RUNS (16-30), not initial runs.
|
||||
This is post-warmup adaptation, not initial cache fill."
|
||||
|
||||
METRIC FOR PAPER: "Convergence Rate: ΔP/Δt = 25.4% / 15 runs ≈ 1.7% per run"
|
||||
|
||||
================================================================================
|
||||
CLAIM 3: STABILITY UNDER ENVIRONMENTAL STRESS
|
||||
================================================================================
|
||||
|
||||
STATEMENT:
|
||||
"The algorithm maintains internal stability (0% variance) despite
|
||||
external environmental noise (70% variance), proving robustness."
|
||||
|
||||
SUPPORTING EVIDENCE:
|
||||
- Internal variance (algorithm): Cache hits = 0% CV
|
||||
- External variance (OS): Runtime = 60-70% CV
|
||||
- Separation: Algorithm behavior independent of OS scheduling
|
||||
|
||||
FORMAL DEFINITION:
|
||||
Stability = Variance_internal / Variance_external
|
||||
= 0% / 70%
|
||||
= Perfect stability
|
||||
|
||||
The algorithm output (cache hits) shows zero correlation with
|
||||
environmental factors (OS scheduling), proving decoupling.
|
||||
|
||||
DEFENSE AGAINST REVIEWERS:
|
||||
Q: "Doesn't 70% variance make your system unpredictable?"
|
||||
A: "No. This is the critical insight:
|
||||
- 70% variance comes from OS scheduling (external)
|
||||
- Algorithm itself has 0% variance (internal)
|
||||
|
||||
The system has INFINITE stability margin. It is robust to
|
||||
extreme environmental noise while maintaining algorithmic purity."
|
||||
|
||||
Q: "How can you claim 0% variance when runtime varies 70%?"
|
||||
A: "Excellent question. This shows the power of variance decomposition:
|
||||
|
||||
Runtime variance = Algorithm variance + OS variance
|
||||
70% total CV = 0% algorithm + 70% OS
|
||||
|
||||
The algorithm deterministically selects same cache configuration
|
||||
on each run. OS scheduling then adds 70% variance on top.
|
||||
|
||||
Analogy: A perfect algorithm running on a noisy OS."
|
||||
|
||||
Q: "Isn't some of that 0% just lucky data?"
|
||||
A: "We collected 60 data points for cache behavior (30 runs × B_CACHE + C_FULL).
|
||||
All 60 show identical 17.39% hit rate. The probability of this by
|
||||
chance is astronomically low."
|
||||
|
||||
METRIC FOR PAPER: "Stability Margin: σ_algorithm / σ_environment = 0/70 = ∞"
|
||||
|
||||
================================================================================
|
||||
CLAIM 4: QUANTIFIABLE & PREDICTABLE PERFORMANCE BOUNDS
|
||||
================================================================================
|
||||
|
||||
STATEMENT:
|
||||
"Performance is bounded within quantifiable ranges with 95% confidence,
|
||||
enabling safe deployment under formal guarantees."
|
||||
|
||||
SUPPORTING EVIDENCE:
|
||||
- B_CACHE: 7.80 ± 2.52 ms → [5.28, 10.32] ms @ 95% confidence
|
||||
- C_FULL: 8.91 ± 5.36 ms → [3.55, 14.27] ms @ 95% confidence
|
||||
- Confidence intervals are mathematically justified (n=30 per config)
|
||||
|
||||
FORMAL DEFINITION:
|
||||
For any configuration C, performance P(C) satisfies:
|
||||
P(|P(C) - μ(C)| ≤ 2σ(C)) ≥ 0.95
|
||||
|
||||
where μ and σ are empirically measured from 30 runs
|
||||
|
||||
DEFENSE AGAINST REVIEWERS:
|
||||
Q: "Why can you make 95% confidence claims on just 30 runs?"
|
||||
A: "Two reasons:
|
||||
(1) Sample size: Central Limit Theorem applies at n=30
|
||||
(2) Data distribution: Empirically approximately normal (verify with Q-Q plot)
|
||||
(3) Mathematical backing: Chebyshev's inequality guarantees 75%,
|
||||
normal distribution assumption gives 95%
|
||||
|
||||
We're not claiming absolute truth, but 95% statistical confidence."
|
||||
|
||||
Q: "Aren't confidence intervals just an illusion?"
|
||||
A: "No. They're empirically grounded:
|
||||
- Collected 30 independent samples per configuration
|
||||
- Measured mean and variance directly
|
||||
- Applied well-established statistical formulas
|
||||
- Confidence interval reflects real data uncertainty
|
||||
|
||||
If you rerun the experiment, your results should fall within
|
||||
these bounds 95% of the time (on same hardware)."
|
||||
|
||||
METRIC FOR PAPER: "Performance Bounds (95% confidence):
|
||||
B_CACHE: 7.80 ± 5.04 ms
|
||||
C_FULL: 8.91 ± 10.72 ms"
|
||||
|
||||
================================================================================
|
||||
CLAIM 5: PHYSICS MODEL ENABLES FORMAL VERIFICATION
|
||||
================================================================================
|
||||
|
||||
STATEMENT:
|
||||
"The physics-based model (execution_heat tracking) is observable,
|
||||
measurable, and enables formal verification of system properties."
|
||||
|
||||
SUPPORTING EVIDENCE:
|
||||
- Execution_heat is directly observable (word frequency counter)
|
||||
- Cache promotion is deterministically triggered (threshold-based)
|
||||
- Model state is reproducible (same program → same heat distribution)
|
||||
|
||||
FORMAL DEFINITION:
|
||||
Physics Model State Machine:
|
||||
|
||||
State = {execution_heat[w] for all words w}
|
||||
Input = {word sequence from program}
|
||||
Output = {cache configuration}
|
||||
|
||||
Transition rules:
|
||||
For each word w executed:
|
||||
execution_heat[w] ← execution_heat[w] + 1
|
||||
if execution_heat[w] ≥ THRESHOLD:
|
||||
cache_config ← cache_config ∪ {w}
|
||||
|
||||
DEFENSE AGAINST REVIEWERS:
|
||||
Q: "This is just a simple counter - why call it 'physics-based'?"
|
||||
A: "True, it's simple. But that's a feature, not a bug:
|
||||
(1) Simplicity enables formal verification (you can axiomatize it)
|
||||
(2) 'Physics-based' refers to the particle state machine framework
|
||||
(3) Execution_heat is analogous to thermal energy (high heat → optimization)
|
||||
(4) The model is deterministic and verifiable in Isabelle/HOL
|
||||
|
||||
We chose simplicity for provability, not for complexity."
|
||||
|
||||
Q: "Is this really novel?"
|
||||
A: "The novelty is in the verification approach:
|
||||
- Showing that a simple physics model can optimize a FORTH VM
|
||||
- Empirically proving convergence and stability
|
||||
- Formal framework connecting runtime model to observable behavior
|
||||
- Variance decomposition as a verification technique
|
||||
|
||||
Individual components (adaptive caching, frequency counting) are known.
|
||||
The integrated verification story is novel."
|
||||
|
||||
METRIC FOR PAPER: "Model Complexity: O(n) state, O(1) per transition"
|
||||
|
||||
================================================================================
|
||||
SUMMARY: WHAT YOU CAN CLAIM TO REVIEWERS
|
||||
================================================================================
|
||||
|
||||
✓ PROVABLE CLAIMS (Directly supported by data):
|
||||
|
||||
1. "Our system is deterministic"
|
||||
Support: 0% variance in algorithm output
|
||||
|
||||
2. "Our system adapts toward optimal configuration"
|
||||
Support: 25% improvement in C_FULL, no improvement in non-adaptive configs
|
||||
|
||||
3. "Our system is stable"
|
||||
Support: 0% internal variance despite 70% external variance
|
||||
|
||||
4. "Our system has predictable performance"
|
||||
Support: 95% confidence intervals empirically established
|
||||
|
||||
5. "Our physics model is observable and verifiable"
|
||||
Support: Execution_heat is directly measurable, formally definable
|
||||
|
||||
✗ CLAIMS TO AVOID (Not directly supported):
|
||||
|
||||
- "Our system is optimal"
|
||||
(You've shown it converges toward optimal, not that it achieves it)
|
||||
|
||||
- "Our system beats all other approaches"
|
||||
(You've shown it works, not that it's better than alternatives)
|
||||
|
||||
- "This is the first self-adaptive VM"
|
||||
(Correct: credit prior work, focus on verification contribution)
|
||||
|
||||
================================================================================
|
||||
PEER REVIEW RESPONSE TEMPLATE
|
||||
================================================================================
|
||||
|
||||
When reviewers challenge your claims:
|
||||
|
||||
1. Acknowledge valid concern
|
||||
2. Point to specific data
|
||||
3. Explain methodology
|
||||
4. Offer clarification
|
||||
|
||||
EXAMPLE EXCHANGE:
|
||||
|
||||
Reviewer: "Your variance numbers don't seem right. How can you have 0%
|
||||
variance when runtimes vary 70%?"
|
||||
|
||||
Your Response: "Excellent point. This is the key insight of our analysis.
|
||||
We decomposed variance into two components:
|
||||
|
||||
INTERNAL variance (algorithm-controlled):
|
||||
Cache hit rates: 17.39% ± 0.00% (CV = 0%)
|
||||
|
||||
EXTERNAL variance (OS-controlled):
|
||||
Runtime fluctuation: 60-70% CV (from scheduling)
|
||||
|
||||
The algorithm selects identical cache configurations every run (0% variance).
|
||||
The OS scheduler then adds its own 70% variance on top.
|
||||
|
||||
See Table 3 in the paper for the full variance decomposition breakdown.
|
||||
Raw data available in appendix for verification."
|
||||
|
||||
================================================================================
|
||||
FINAL CHECKLIST FOR PEER REVIEW
|
||||
================================================================================
|
||||
|
||||
Before submitting, verify you can defend:
|
||||
|
||||
□ Claim 1 (Determinism):
|
||||
- Raw data showing 0% cache hit rate variance ✓
|
||||
- Explanation of variance decomposition ✓
|
||||
- Defense against "measurement noise" charge ✓
|
||||
|
||||
□ Claim 2 (Convergence):
|
||||
- Comparison of all three configurations ✓
|
||||
- Explanation why non-adaptive configs don't converge ✓
|
||||
- Defense against "this is just JIT" argument ✓
|
||||
|
||||
□ Claim 3 (Stability):
|
||||
- Proof that algorithm variance ≠ runtime variance ✓
|
||||
- Explanation of robustness to external noise ✓
|
||||
- Defense against "70% variance is too high" ✓
|
||||
|
||||
□ Claim 4 (Predictability):
|
||||
- Statistical justification for confidence intervals ✓
|
||||
- Sample size adequacy (n=30) ✓
|
||||
- Defense against "confidence intervals are meaningless" ✓
|
||||
|
||||
□ Claim 5 (Physics Model):
|
||||
- Model description clear and formal ✓
|
||||
- Observable state definition ✓
|
||||
- Transition rules explicitly stated ✓
|
||||
|
||||
□ Supporting Evidence:
|
||||
- All data reproducible from raw CSV ✓
|
||||
- Analysis scripts provided ✓
|
||||
- Methodology clearly documented ✓
|
||||
|
||||
================================================================================
|
||||
GO SUBMIT WITH CONFIDENCE
|
||||
================================================================================
|
||||
|
||||
Your experimental work is solid.
|
||||
Your data is clean.
|
||||
Your analysis is rigorous.
|
||||
Your claims are defensible.
|
||||
|
||||
You have empirically proven:
|
||||
✓ Physics model produces deterministic behavior
|
||||
✓ System demonstrates adaptive convergence
|
||||
✓ Algorithm is stable despite environmental noise
|
||||
✓ Performance bounds are predictable
|
||||
|
||||
This is formal verification through empirical validation.
|
||||
|
||||
Ready for peer review. Good luck!
|
||||
|
||||
================================================================================
|
||||
-179
@@ -1,179 +0,0 @@
|
||||
================================================================================
|
||||
PHYSICS ENGINE VALIDATION - QUICK REFERENCE GUIDE
|
||||
================================================================================
|
||||
|
||||
EXPERIMENTS COMPLETED:
|
||||
✓ 90-run comprehensive validation (3 configs × 30 runs each)
|
||||
✓ CPU thermal monitoring (captured temperature & frequency)
|
||||
✓ Data integrity validation (all 90 rows clean)
|
||||
✓ Thermal hypothesis testing (REFUTED - no thermal noise)
|
||||
✓ Variance source analysis (identified OS scheduling + memory latency)
|
||||
|
||||
CURRENT STATE:
|
||||
Location: /home/rajames/CLionProjects/StarForth/physics_experiment/full_90_run_comprehensive/
|
||||
Results: experiment_results.csv (90 runs, all data validated)
|
||||
Analysis Files:
|
||||
- analyze_thermal_hypothesis.py (thermal analysis)
|
||||
- analyze_variance_sources.py (variance decomposition)
|
||||
- VARIANCE_ANALYSIS_SUMMARY.md (comprehensive findings)
|
||||
|
||||
================================================================================
|
||||
KEY FINDINGS AT A GLANCE
|
||||
================================================================================
|
||||
|
||||
THERMAL HYPOTHESIS: ✗ REFUTED
|
||||
- CPU remained at exactly 27°C throughout all 90 runs
|
||||
- No thermal drift, no frequency throttling
|
||||
- Conclusion: Thermal noise is NOT a factor in your measurements
|
||||
|
||||
VARIANCE SOURCE RANKING (Coefficient of Variation):
|
||||
|
||||
1. OS SCHEDULING NOISE (PRIMARY) - 60-70% CV ⚠️
|
||||
A_BASELINE: 69.58% (range: 3.34-17.67ms, 305% span!)
|
||||
C_FULL: 60.23% (range: 6.56-33.15ms, 299% span!)
|
||||
B_CACHE: 32.35% (range: 6.27-19.26ms, 167% span)
|
||||
|
||||
→ This is the DOMINANT source of variance
|
||||
→ Simple configs are WORSE (more sensitive to preemption)
|
||||
→ Caused by: context switching, interrupts, page faults
|
||||
|
||||
2. MEMORY LATENCY VARIABILITY (SECONDARY) - 54-103% CV ⚠️
|
||||
B_CACHE cache hit latency: 40.1 ns ± 41.4 ns (103.3% CV)
|
||||
C_FULL cache hit latency: 37.9 ns ± 20.5 ns (54.0% CV)
|
||||
|
||||
→ Extreme variability in L1/L2 hit times
|
||||
→ Indicates cache coherency misses, NUMA effects
|
||||
→ 80ns swings in what should be 40ns hits
|
||||
|
||||
3. CACHE HIT RATE (EXCELLENT) - 0% CV ✓
|
||||
B_CACHE: 17.39% ± 0.00%
|
||||
C_FULL: 17.39% ± 0.00%
|
||||
|
||||
→ Perfect consistency! Cache behavior is deterministic
|
||||
→ Variance NOT from unpredictable cache misses
|
||||
→ Working set is stable across all runs
|
||||
|
||||
4. WARMUP EFFECTS (INTERESTING) - -25% to +6%
|
||||
A_BASELINE: +6.4% slower (degradation over time)
|
||||
B_CACHE: +0.5% stable (excellent warmup)
|
||||
C_FULL: -25.4% FASTER (improves significantly!)
|
||||
|
||||
→ C_FULL benefits from warming caches
|
||||
→ A_BASELINE shows slight system degradation
|
||||
|
||||
================================================================================
|
||||
QUICK FIXES (DO THIS NOW)
|
||||
================================================================================
|
||||
|
||||
STEP 1: CPU PINNING (Expected improvement: -30-40% variance)
|
||||
Run your benchmark pinned to a single CPU core:
|
||||
$ taskset -c 0 ./build/starforth ...
|
||||
|
||||
Or for the experiment:
|
||||
$ taskset -c 0 scripts/run_comprehensive_physics_experiment.sh ...
|
||||
|
||||
STEP 2: SET PERFORMANCE MODE (Expected improvement: -10-15% variance)
|
||||
Disable frequency scaling:
|
||||
$ echo performance | sudo tee /sys/devices/system/cpu/*/cpufreq/scaling_governor
|
||||
|
||||
Verify:
|
||||
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
|
||||
|
||||
STEP 3: USE ROBUST STATISTICS (Immediate improvement)
|
||||
Don't use mean ± stdev when you have 69% CV!
|
||||
|
||||
Instead, use trimmed mean:
|
||||
- Sort runtimes
|
||||
- Remove top/bottom 10%
|
||||
- Average the middle 80%
|
||||
|
||||
Or use median + IQR (interquartile range)
|
||||
|
||||
Python example:
|
||||
runtimes = [4.5, 4.7, 5.2, 17.6] # 17.6 is outlier
|
||||
sorted_rt = sorted(runtimes)
|
||||
trimmed = sorted_rt[1:-1] # Remove min and max
|
||||
mean = sum(trimmed) / len(trimmed)
|
||||
|
||||
COMBINED EXPECTED IMPROVEMENT:
|
||||
Current: A_BASELINE ~70% CV
|
||||
After Step 1+2: ~30-40% CV
|
||||
After Step 3: Statistics properly account for outliers
|
||||
|
||||
Result: Much clearer performance comparisons!
|
||||
|
||||
================================================================================
|
||||
DETAILED MITIGATION PRIORITY
|
||||
================================================================================
|
||||
|
||||
IMMEDIATE (This week):
|
||||
[1] CPU pinning with taskset
|
||||
[2] Performance governor setting
|
||||
[3] Rerun experiment with CPU pinning
|
||||
[4] Switch to trimmed mean analysis
|
||||
|
||||
SHORT TERM (Next 1-2 weeks):
|
||||
[1] Disable SMT (hyper-threading)
|
||||
[2] Increase warmup phase (5 runs instead of current)
|
||||
[3] Use perf to measure cache misses
|
||||
$ perf stat -e cache-references,cache-misses \
|
||||
taskset -c 0 ./build/starforth ...
|
||||
|
||||
MEDIUM TERM (If variance still >30%):
|
||||
[1] Try SCHED_FIFO real-time scheduling (requires root)
|
||||
[2] NUMA binding with numactl
|
||||
[3] Isolate CPU cores (kernel parameter isolcpus)
|
||||
[4] Profile with perf-record to find hotspots
|
||||
|
||||
LONG TERM (For production benchmarks):
|
||||
[1] Use real-time kernel (RT_PREEMPT)
|
||||
[2] Dedicated measurement system
|
||||
[3] Disable all background services
|
||||
|
||||
================================================================================
|
||||
FILES TO READ
|
||||
================================================================================
|
||||
|
||||
DETAILED ANALYSIS:
|
||||
→ /home/rajames/CLionProjects/StarForth/physics_experiment/VARIANCE_ANALYSIS_SUMMARY.md
|
||||
(Full findings, root cause analysis, mitigation strategies)
|
||||
|
||||
DATA FILES:
|
||||
→ /home/rajames/CLionProjects/StarForth/physics_experiment/full_90_run_comprehensive/
|
||||
experiment_results.csv (90 rows of clean data, all metrics)
|
||||
|
||||
ANALYSIS SCRIPTS:
|
||||
→ analyze_thermal_hypothesis.py (thermal analysis)
|
||||
→ analyze_variance_sources.py (variance decomposition - rerun anytime)
|
||||
|
||||
================================================================================
|
||||
QUICK TEST: VALIDATE IMPROVEMENTS
|
||||
================================================================================
|
||||
|
||||
After applying mitigations, rerun and compare:
|
||||
|
||||
# Before mitigations (baseline)
|
||||
$ ./scripts/run_comprehensive_physics_experiment.sh before_fix
|
||||
$ python3 analyze_variance_sources.py \
|
||||
before_fix/experiment_results.csv
|
||||
|
||||
# After mitigations
|
||||
$ taskset -c 0 ./scripts/run_comprehensive_physics_experiment.sh after_fix
|
||||
$ python3 analyze_variance_sources.py \
|
||||
after_fix/experiment_results.csv
|
||||
|
||||
Expected: Coefficient of Variation drops from 60-70% to <40%
|
||||
|
||||
================================================================================
|
||||
BOTTOM LINE
|
||||
================================================================================
|
||||
|
||||
Your data collection script: ✓ PERFECT (no issues found)
|
||||
Your thermal hypothesis: ✗ NOT CONFIRMED (system is cool)
|
||||
Your actual problem: → OS scheduling noise (expected, solvable)
|
||||
|
||||
Next action: Pin to CPU + set performance mode, then rerun.
|
||||
Expected result: Variance cut by 40% or more.
|
||||
|
||||
For questions, see VARIANCE_ANALYSIS_SUMMARY.md for full technical details.
|
||||
================================================================================
|
||||
-16
@@ -1,16 +0,0 @@
|
||||
|
||||
Experiment Start: 2025-11-07T06:40:43
|
||||
Output Directory: physics_experiment/full_90_run_comprehensive
|
||||
Runs per Configuration: 30
|
||||
Total Runs: 90
|
||||
Benchmark Iterations: 100000
|
||||
Build Profile: fastest
|
||||
Execution: Randomized order (eliminates temporal bias)
|
||||
|
||||
|
||||
Experiment End: 2025-11-07T06:49:08
|
||||
Total Runtime: 8 minutes (505 seconds)
|
||||
Results CSV: physics_experiment/full_90_run_comprehensive/experiment_results.csv
|
||||
Run Logs: physics_experiment/full_90_run_comprehensive/run_logs/
|
||||
Test Matrix: physics_experiment/full_90_run_comprehensive/run_logs/test_matrix.txt
|
||||
|
||||
-90
@@ -1,90 +0,0 @@
|
||||
A_BASELINE,0,0,8
|
||||
B_CACHE,1,0,21
|
||||
A_BASELINE,0,0,17
|
||||
B_CACHE,1,0,25
|
||||
C_FULL,1,1,23
|
||||
B_CACHE,1,0,7
|
||||
B_CACHE,1,0,16
|
||||
B_CACHE,1,0,13
|
||||
B_CACHE,1,0,30
|
||||
C_FULL,1,1,26
|
||||
A_BASELINE,0,0,28
|
||||
C_FULL,1,1,16
|
||||
B_CACHE,1,0,22
|
||||
A_BASELINE,0,0,24
|
||||
A_BASELINE,0,0,18
|
||||
B_CACHE,1,0,8
|
||||
C_FULL,1,1,12
|
||||
A_BASELINE,0,0,19
|
||||
C_FULL,1,1,4
|
||||
A_BASELINE,0,0,3
|
||||
C_FULL,1,1,14
|
||||
B_CACHE,1,0,9
|
||||
A_BASELINE,0,0,11
|
||||
A_BASELINE,0,0,10
|
||||
C_FULL,1,1,22
|
||||
B_CACHE,1,0,1
|
||||
B_CACHE,1,0,28
|
||||
C_FULL,1,1,15
|
||||
C_FULL,1,1,1
|
||||
C_FULL,1,1,30
|
||||
A_BASELINE,0,0,13
|
||||
C_FULL,1,1,29
|
||||
B_CACHE,1,0,11
|
||||
B_CACHE,1,0,3
|
||||
A_BASELINE,0,0,29
|
||||
C_FULL,1,1,6
|
||||
A_BASELINE,0,0,20
|
||||
A_BASELINE,0,0,15
|
||||
B_CACHE,1,0,14
|
||||
B_CACHE,1,0,5
|
||||
C_FULL,1,1,20
|
||||
A_BASELINE,0,0,16
|
||||
C_FULL,1,1,3
|
||||
A_BASELINE,0,0,23
|
||||
B_CACHE,1,0,6
|
||||
A_BASELINE,0,0,30
|
||||
A_BASELINE,0,0,7
|
||||
C_FULL,1,1,19
|
||||
C_FULL,1,1,5
|
||||
B_CACHE,1,0,15
|
||||
B_CACHE,1,0,29
|
||||
C_FULL,1,1,13
|
||||
C_FULL,1,1,9
|
||||
C_FULL,1,1,25
|
||||
A_BASELINE,0,0,4
|
||||
B_CACHE,1,0,17
|
||||
C_FULL,1,1,21
|
||||
C_FULL,1,1,17
|
||||
B_CACHE,1,0,20
|
||||
B_CACHE,1,0,26
|
||||
C_FULL,1,1,11
|
||||
A_BASELINE,0,0,27
|
||||
B_CACHE,1,0,18
|
||||
B_CACHE,1,0,12
|
||||
C_FULL,1,1,2
|
||||
A_BASELINE,0,0,25
|
||||
A_BASELINE,0,0,14
|
||||
C_FULL,1,1,24
|
||||
C_FULL,1,1,8
|
||||
B_CACHE,1,0,27
|
||||
B_CACHE,1,0,4
|
||||
C_FULL,1,1,7
|
||||
A_BASELINE,0,0,9
|
||||
A_BASELINE,0,0,2
|
||||
C_FULL,1,1,18
|
||||
B_CACHE,1,0,19
|
||||
A_BASELINE,0,0,21
|
||||
A_BASELINE,0,0,22
|
||||
C_FULL,1,1,28
|
||||
A_BASELINE,0,0,12
|
||||
A_BASELINE,0,0,26
|
||||
B_CACHE,1,0,24
|
||||
B_CACHE,1,0,10
|
||||
B_CACHE,1,0,2
|
||||
B_CACHE,1,0,23
|
||||
A_BASELINE,0,0,6
|
||||
A_BASELINE,0,0,5
|
||||
C_FULL,1,1,10
|
||||
C_FULL,1,1,27
|
||||
A_BASELINE,0,0,1
|
||||
@@ -1,528 +0,0 @@
|
||||
<!-- Moved from docs/reference/ONTOLOGY.md to docs/working/papers/ONTOLOGY.md on 2026-06-16 (docs reorg Phase 2) -->
|
||||
# StarForth Ontology, Taxonomy, and Lexicon
|
||||
|
||||
**Version**: 1.0
|
||||
**Date**: 2025-12-13
|
||||
**Purpose**: Formal conceptual framework for precise academic discourse
|
||||
|
||||
---
|
||||
|
||||
## I. ONTOLOGY (Conceptual Framework)
|
||||
|
||||
### 1.1 Core Concepts
|
||||
|
||||
```
|
||||
StarForth Adaptive Runtime System
|
||||
├── Execution Metrics
|
||||
│ ├── Execution Frequency (primary measurable)
|
||||
│ ├── Temporal Decay (derived quantity)
|
||||
│ └── Transition Probability (derived quantity)
|
||||
├── Adaptive Mechanisms
|
||||
│ ├── Frequency-Based Caching
|
||||
│ ├── Window-Based Inference
|
||||
│ └── Decay-Based Pruning
|
||||
├── Convergence Properties
|
||||
│ ├── Deterministic Behavior
|
||||
│ ├── Steady-State Equilibrium
|
||||
│ └── Variance Reduction
|
||||
└── Analysis Frameworks
|
||||
├── Dynamical Systems View
|
||||
├── Statistical Inference View
|
||||
└── Control Theory View
|
||||
```
|
||||
|
||||
### 1.2 Conceptual Relationships
|
||||
|
||||
```
|
||||
METAPHORICAL MAPPING (Thermodynamics → Execution):
|
||||
Thermal Energy ≈ Execution Frequency (measurable count)
|
||||
Heat Dissipation ≈ Exponential Decay (time-based reduction)
|
||||
Thermal Equilibrium ≈ Steady-State Convergence (stable metrics)
|
||||
Temperature ≈ Normalized Frequency Rank
|
||||
Cooling Rate ≈ Decay Coefficient (λ)
|
||||
|
||||
LITERAL IMPLEMENTATIONS (No Metaphor):
|
||||
Frequency Counter → Integer increment on execution
|
||||
Decay Function → f(t) = f₀ * e^(-λt)
|
||||
Hot-Words Cache → Top-K frequency-sorted entries
|
||||
Rolling Window → Circular buffer of execution records
|
||||
ANOVA Test → Statistical variance analysis (Levene's test)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## II. TAXONOMY (Hierarchical Classification)
|
||||
|
||||
### 2.1 Adaptive Runtime Components
|
||||
|
||||
```
|
||||
1. Measurement Layer
|
||||
1.1 Execution Frequency Tracking
|
||||
└── Dictionary Entry Counter (per-word increment)
|
||||
1.2 Temporal Recording
|
||||
└── Rolling Window of Truth (circular buffer)
|
||||
1.3 Transition Tracking
|
||||
└── Word-to-Word Transition Matrix
|
||||
|
||||
2. Transformation Layer
|
||||
2.1 Decay Models
|
||||
2.1.1 Linear Decay (Loop #3)
|
||||
└── Δf = -k * Δt
|
||||
2.1.2 Exponential Decay (Loop #6 Inference)
|
||||
└── f(t) = f₀ * e^(-λt)
|
||||
2.2 Normalization
|
||||
2.2.1 Frequency Ranking
|
||||
2.2.2 Probability Calculation
|
||||
|
||||
3. Inference Layer
|
||||
3.1 Window Width Inference (Loop #5)
|
||||
3.1.1 Variance Analysis (Levene's Test)
|
||||
3.1.2 Binary Search (Variance Inflection Point)
|
||||
3.2 Decay Slope Inference (Loop #6)
|
||||
3.2.1 Exponential Regression
|
||||
3.2.2 Least Squares Fitting
|
||||
|
||||
4. Actuation Layer
|
||||
4.1 Hot-Words Cache (Loop #1)
|
||||
4.1.1 Frequency-Based Sorting
|
||||
4.1.2 Top-K Selection
|
||||
4.1.3 Fast-Path Dictionary Lookup
|
||||
4.2 Speculative Execution (Loop #4)
|
||||
4.2.1 Transition Probability Calculation
|
||||
4.2.2 Prefetch Decision
|
||||
|
||||
5. Coordination Layer
|
||||
5.1 Heartbeat System (Loop #7)
|
||||
5.1.1 Time-Driven Tick Generation
|
||||
5.1.2 Loop Orchestration
|
||||
5.1.3 Adaptive Tick Rate
|
||||
```
|
||||
|
||||
### 2.2 Feedback Loop Taxonomy
|
||||
|
||||
```
|
||||
Feedback Loops (7 Total)
|
||||
├── Positive Loops (Amplifying)
|
||||
│ ├── Loop #1: Execution Heat Tracking
|
||||
│ │ └── More executions → Higher rank → More cache hits → More executions
|
||||
│ └── Loop #4: Pipelining Metrics
|
||||
│ └── More transitions → Better prediction → More prefetch hits
|
||||
├── Negative Loops (Stabilizing)
|
||||
│ ├── Loop #3: Linear Decay
|
||||
│ │ └── High frequency → Faster decay → Lower frequency → Slower decay
|
||||
│ ├── Loop #5: Window Width Inference
|
||||
│ │ └── High variance → Smaller window → Lower variance
|
||||
│ └── Loop #6: Decay Slope Inference
|
||||
│ └── Unstable metrics → Steeper decay → Faster stabilization
|
||||
├── Neutral Loops (Monitoring)
|
||||
│ └── Loop #2: Rolling Window History
|
||||
│ └── Execution occurs → Record in window → Historical data available
|
||||
└── Meta-Loop (Adaptive Coordination)
|
||||
└── Loop #7: Adaptive Heartbeat
|
||||
└── Stable system → Slower ticks → Less overhead
|
||||
```
|
||||
|
||||
### 2.3 Convergence Taxonomy
|
||||
|
||||
```
|
||||
Convergence Properties
|
||||
├── Determinism
|
||||
│ ├── Algorithmic Determinism (same inputs → same outputs)
|
||||
│ ├── Temporal Determinism (time-invariant steady state)
|
||||
│ └── Statistical Determinism (0% variance)
|
||||
├── Steady-State Characteristics
|
||||
│ ├── Fixed Point (attractors in phase space)
|
||||
│ ├── Periodic Behavior (limit cycles)
|
||||
│ └── Chaotic Behavior (sensitive dependence - avoided)
|
||||
└── Variance Metrics
|
||||
├── Inter-Run Variance (across multiple executions)
|
||||
├── Intra-Run Variance (within single execution)
|
||||
└── Temporal Variance (across time windows)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## III. LEXICON (Precise Definitions)
|
||||
|
||||
### 3.1 Core Terms (Alphabetical)
|
||||
|
||||
**Adaptive Heartbeat**
|
||||
*Definition*: Time-driven coordination mechanism that orchestrates feedback loop execution at dynamically-adjusted intervals.
|
||||
*Formal*: Thread T executing `vm_tick()` at frequency f_tick, where f_tick ∈ [f_min, f_max] adapts based on system stability.
|
||||
*Measurement*: Tick period in nanoseconds (configurable: HEARTBEAT_TICK_NS).
|
||||
*Category*: Coordination mechanism.
|
||||
|
||||
**Attractor**
|
||||
*Definition*: Stable equilibrium point or region in phase space toward which execution trajectories converge.
|
||||
*Formal*: Fixed point x* where F(x*) = x* for dynamical system x_{t+1} = F(x_t).
|
||||
*Measurement*: Coordinates in (window_size, decay_slope, variance) space.
|
||||
*Category*: Dynamical systems concept.
|
||||
|
||||
**Decay Coefficient (λ)**
|
||||
*Definition*: Rate parameter controlling exponential reduction in execution frequency over time.
|
||||
*Formal*: λ in f(t) = f₀ * e^(-λt), units of [1/time].
|
||||
*Measurement*: Derived via exponential regression; stored as Q48.16 fixed-point.
|
||||
*Category*: Transformation parameter.
|
||||
|
||||
**Deterministic Convergence**
|
||||
*Definition*: Property whereby repeated executions of identical workloads produce statistically indistinguishable steady-state metrics.
|
||||
*Formal*: ∀ executions i,j: |metric_i - metric_j| / σ < ε, where ε → 0 as t → ∞.
|
||||
*Measurement*: Coefficient of variation CV = σ/μ → 0%.
|
||||
*Category*: Convergence property.
|
||||
|
||||
**Execution Frequency**
|
||||
*Definition*: Count of times a dictionary entry has been executed since VM initialization, optionally adjusted by decay.
|
||||
*Formal*: f = Σ executions - ∫ decay(t) dt.
|
||||
*Measurement*: Unsigned 64-bit integer (`uint64_t execution_heat`).
|
||||
*Category*: Primary measurable quantity.
|
||||
*Note*: "Heat" is metaphorical naming; actual quantity is frequency.
|
||||
|
||||
**Exponential Decay**
|
||||
*Definition*: Mathematical function modeling reduction in execution frequency proportional to current value.
|
||||
*Formal*: f(t) = f₀ * e^(-λt), where f₀ is initial frequency.
|
||||
*Measurement*: Applied periodically by heartbeat system.
|
||||
*Category*: Transformation function.
|
||||
*Metaphor*: Analogous to radioactive decay or thermal dissipation.
|
||||
|
||||
**Hot-Words Cache**
|
||||
*Definition*: Fixed-size array storing pointers to the K most frequently executed dictionary entries for O(1) lookup acceleration.
|
||||
*Formal*: Cache C = {e_1, e_2, ..., e_K} where f(e_i) ≥ f(e_{i+1}) ∀ i.
|
||||
*Measurement*: Cache size K (configurable: HOTWORDS_CACHE_SIZE).
|
||||
*Category*: Frequency-based optimization.
|
||||
|
||||
**Levene's Test**
|
||||
*Definition*: Non-parametric statistical test for homogeneity of variance across groups.
|
||||
*Formal*: H₀: σ₁² = σ₂² = ... = σ_k² (variances equal).
|
||||
*Measurement*: F-statistic with p-value threshold (typically 0.05).
|
||||
*Category*: Statistical inference method.
|
||||
*Application*: Used to detect variance changes when adjusting window size.
|
||||
|
||||
**Phase Space**
|
||||
*Definition*: Multi-dimensional coordinate system where each axis represents a system state variable.
|
||||
*Formal*: Space S = {(w, λ, σ²) | w ∈ ℕ, λ ∈ ℝ⁺, σ² ∈ ℝ⁺}.
|
||||
*Measurement*: Coordinates: (window_size, decay_slope_Q48, variance_Q48).
|
||||
*Category*: Dynamical systems representation.
|
||||
|
||||
**Rolling Window of Truth**
|
||||
*Definition*: Circular buffer recording recent execution history for deterministic metric seeding.
|
||||
*Formal*: Buffer B[i] = word_id at execution event i mod |B|.
|
||||
*Measurement*: Buffer size (configurable: ROLLING_WINDOW_SIZE = 4096).
|
||||
*Category*: Temporal recording mechanism.
|
||||
*Purpose*: Ensures identical initial conditions for reproducibility.
|
||||
|
||||
**Steady-State Equilibrium**
|
||||
*Definition*: Condition where adaptive system metrics stabilize within bounded oscillation.
|
||||
*Formal*: ∃ t_0: ∀ t > t_0, |x(t) - x*| < δ for small δ.
|
||||
*Measurement*: Variance CV < 0.1% over 1000-tick window.
|
||||
*Category*: Convergence property.
|
||||
*Metaphor*: Analogous to thermodynamic equilibrium.
|
||||
|
||||
**Thermodynamic Metaphor**
|
||||
*Definition*: Conceptual mapping between thermodynamic quantities and execution metrics.
|
||||
*Mapping*:
|
||||
- Heat ↔ Execution Frequency
|
||||
- Temperature ↔ Normalized Rank
|
||||
- Cooling ↔ Exponential Decay
|
||||
- Equilibrium ↔ Steady State
|
||||
*Category*: Conceptual framework (not literal physics).
|
||||
*Warning*: Must qualify as metaphor in academic writing.
|
||||
|
||||
**Transition Probability**
|
||||
*Definition*: Conditional probability that word B is executed immediately after word A.
|
||||
*Formal*: P(B|A) = count(A→B) / count(A).
|
||||
*Measurement*: Stored as Q48.16 fixed-point in transition matrix.
|
||||
*Category*: Derived metric for speculative execution.
|
||||
|
||||
**Variance Inflection Point**
|
||||
*Definition*: Window size w* where variance begins to increase when window shrinks below w*.
|
||||
*Formal*: w* = arg min_w { Var(w) | w < w_current }.
|
||||
*Measurement*: Found via binary search with Levene's test.
|
||||
*Category*: Inference target.
|
||||
*Purpose*: Optimal window size for stable metrics.
|
||||
|
||||
**Word Transition**
|
||||
*Definition*: Sequential execution of word B immediately following word A in threaded code.
|
||||
*Formal*: Event (A, B, t) where A executes at time t and B at time t+ε.
|
||||
*Measurement*: Recorded in transition_metrics.history[] circular buffer.
|
||||
*Category*: Execution event.
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Avoid/Deprecated Terms
|
||||
|
||||
| ❌ Avoid | ✅ Use Instead | Reason |
|
||||
|---------|---------------|--------|
|
||||
| "Physics-based" | "Thermodynamically-inspired metaphor" | Not literal physics |
|
||||
| "Execution heat" (in formal writing) | "Execution frequency with decay" | "Heat" is metaphorical |
|
||||
| "Temperature" | "Normalized frequency rank" | No actual thermal quantity |
|
||||
| "Quantum-inspired" | N/A | No quantum mechanics involved |
|
||||
| "AI-driven" | "Statistically-inferred" | No neural networks or ML |
|
||||
| "Learning" | "Adaptive inference" | Not machine learning |
|
||||
| "Training" | "Convergence to steady state" | Not supervised learning |
|
||||
|
||||
---
|
||||
|
||||
## IV. MATHEMATICAL FORMALISM
|
||||
|
||||
### 4.1 Execution Frequency Evolution
|
||||
|
||||
**Discrete-time update**:
|
||||
```
|
||||
f[t+1] = f[t] + Δexec[t] - Δdecay[t]
|
||||
|
||||
where:
|
||||
Δexec[t] = 1 if word executed at tick t, else 0
|
||||
Δdecay[t] = λ * f[t] * Δt (exponential decay approximation)
|
||||
```
|
||||
|
||||
**Continuous-time model**:
|
||||
```
|
||||
df/dt = r(t) - λf(t)
|
||||
|
||||
where:
|
||||
r(t) = execution rate [executions/second]
|
||||
λ = decay coefficient [1/second]
|
||||
|
||||
Solution:
|
||||
f(t) = e^(-λt) * [f₀ + ∫₀ᵗ r(τ)e^(λτ) dτ]
|
||||
```
|
||||
|
||||
### 4.2 Hot-Words Cache Selection
|
||||
|
||||
**Cache membership criterion**:
|
||||
```
|
||||
e ∈ Cache ⟺ rank(e) ≤ K
|
||||
|
||||
where:
|
||||
rank(e) = |{e' ∈ Dictionary : f(e') > f(e)}| + 1
|
||||
K = cache size (constant)
|
||||
```
|
||||
|
||||
### 4.3 Window Width Inference
|
||||
|
||||
**Objective function**:
|
||||
```
|
||||
w* = arg min { Var(w) : w ∈ [w_min, w_current] }
|
||||
|
||||
Subject to:
|
||||
Levene(w, w_current) → F-statistic
|
||||
p-value(F) < α (typically α = 0.05)
|
||||
```
|
||||
|
||||
### 4.4 Decay Slope Inference
|
||||
|
||||
**Exponential regression**:
|
||||
```
|
||||
Given: {(t_i, f_i)}_{i=1}^N from rolling window
|
||||
|
||||
Model: f(t) = f₀ * e^(-λt)
|
||||
|
||||
Log-transform: ln(f) = ln(f₀) - λt
|
||||
|
||||
Least squares:
|
||||
λ* = arg min Σ [ln(f_i) - (ln(f₀) - λt_i)]²
|
||||
```
|
||||
|
||||
### 4.5 Transition Probability
|
||||
|
||||
**Maximum likelihood estimate**:
|
||||
```
|
||||
P(B|A) = count(A→B) / count(A)
|
||||
|
||||
where:
|
||||
count(A→B) = # times B executed immediately after A
|
||||
count(A) = # times A executed
|
||||
```
|
||||
|
||||
### 4.6 Convergence Metric
|
||||
|
||||
**Coefficient of Variation**:
|
||||
```
|
||||
CV = σ / μ
|
||||
|
||||
where:
|
||||
σ = √(Var[metric]) = standard deviation
|
||||
μ = E[metric] = mean
|
||||
|
||||
Convergence achieved when: CV → 0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## V. RELATIONSHIP DIAGRAM
|
||||
|
||||
### 5.1 Component Dependencies
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Execution Event │
|
||||
│ (word executed) │
|
||||
└──────────────────────┬──────────────────────────────────────┘
|
||||
│
|
||||
┌───────────┴───────────┐
|
||||
│ │
|
||||
▼ ▼
|
||||
┌────────────────┐ ┌──────────────────┐
|
||||
│ Frequency │ │ Rolling Window │
|
||||
│ Increment │ │ Recording │
|
||||
│ (Loop #1) │ │ (Loop #2) │
|
||||
└────────┬───────┘ └─────────┬────────┘
|
||||
│ │
|
||||
│ │
|
||||
▼ ▼
|
||||
┌────────────────┐ ┌──────────────────┐
|
||||
│ Decay │ │ Inference │
|
||||
│ Application │ │ Engine │
|
||||
│ (Loop #3,#6) │ │ (Loop #5,#6) │
|
||||
└────────┬───────┘ └─────────┬────────┘
|
||||
│ │
|
||||
└───────────┬────────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Hot-Words Cache │
|
||||
│ Reorganization │
|
||||
└───────────┬───────────┘
|
||||
│
|
||||
▼
|
||||
┌───────────────────────┐
|
||||
│ Optimized Lookup │
|
||||
│ (O(1) cache hit) │
|
||||
└───────────────────────┘
|
||||
```
|
||||
|
||||
### 5.2 Feedback Loop Interactions
|
||||
|
||||
```
|
||||
Execution → Frequency ↑ → Cache Rank ↑ → Lookup Speed ↑ → More Execution
|
||||
▲ │
|
||||
│ │
|
||||
└─────────────── (Positive Feedback) ────────────┘
|
||||
|
||||
Frequency ↑ → Decay ↑ → Frequency ↓ → Decay ↓ → Frequency Stabilizes
|
||||
▲ │
|
||||
│ │
|
||||
└──── (Negative Feedback) ────┘
|
||||
|
||||
Variance ↑ → Window Shrink → Variance ↓ → Window Stable
|
||||
▲ │
|
||||
│ │
|
||||
└──── (Negative Feedback) ──┘
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## VI. ONTOLOGICAL COMMITMENTS
|
||||
|
||||
### 6.1 Foundational Assumptions
|
||||
|
||||
1. **Frequency as Proxy for Importance**
|
||||
- Assumption: Frequently executed code is more important to optimize
|
||||
- Justification: Empirical validation (Zipf's law in execution patterns)
|
||||
|
||||
2. **Decay Models Temporal Relevance**
|
||||
- Assumption: Recent executions are more relevant than distant past
|
||||
- Justification: Locality of reference (temporal locality principle)
|
||||
|
||||
3. **Determinism Through Convergence**
|
||||
- Assumption: Adaptive systems can converge to deterministic steady states
|
||||
- Justification: Fixed-point theorems for contractive mappings
|
||||
|
||||
4. **Statistical Inference Validity**
|
||||
- Assumption: Execution patterns are statistically analyzable
|
||||
- Justification: Central Limit Theorem for large sample sizes
|
||||
|
||||
### 6.2 Scope Limitations
|
||||
|
||||
**What This Ontology DOES Cover**:
|
||||
- ✓ Execution frequency measurement and decay
|
||||
- ✓ Adaptive caching and inference mechanisms
|
||||
- ✓ Dynamical systems characterization
|
||||
- ✓ Statistical convergence properties
|
||||
|
||||
**What This Ontology DOES NOT Cover**:
|
||||
- ✗ Actual thermodynamic processes (metaphor only)
|
||||
- ✗ Machine learning or neural networks (no training)
|
||||
- ✗ Quantum computing (no quantum effects)
|
||||
- ✗ Biological neural systems (no biomimicry)
|
||||
|
||||
---
|
||||
|
||||
## VII. USAGE GUIDELINES
|
||||
|
||||
### 7.1 Academic Writing
|
||||
|
||||
**In Abstracts/Titles**: Use precise, non-metaphorical terms
|
||||
```
|
||||
✅ "Thermodynamically-Inspired Adaptive Runtime"
|
||||
❌ "Physics-Based Virtual Machine"
|
||||
```
|
||||
|
||||
**In Technical Sections**: Qualify metaphors explicitly
|
||||
```
|
||||
✅ "We employ a thermodynamic metaphor where execution frequency
|
||||
is treated as 'heat' that dissipates over time..."
|
||||
❌ "The physics model applies heat decay..."
|
||||
```
|
||||
|
||||
**In Formalism**: Use mathematical definitions, not analogies
|
||||
```
|
||||
✅ "Frequency evolves as f(t) = f₀ * e^(-λt)"
|
||||
❌ "Heat cools exponentially like in Newton's law"
|
||||
```
|
||||
|
||||
### 7.2 Code Comments
|
||||
|
||||
**In Source Code**: Use concrete terms from lexicon
|
||||
```c
|
||||
// ✅ GOOD: Increment execution frequency counter
|
||||
entry->execution_heat++;
|
||||
|
||||
// ❌ BAD: Increase temperature of word
|
||||
entry->execution_heat++; // heat up!
|
||||
```
|
||||
|
||||
### 7.3 Presentation/Talks
|
||||
|
||||
**Slides**: Use metaphor for intuition, then formalize
|
||||
```
|
||||
Slide 1: "Think of execution frequency like heat..."
|
||||
Slide 2: "Formally: f(t) = f₀ * e^(-λt)"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## VIII. REFERENCES
|
||||
|
||||
### 8.1 Foundational Concepts
|
||||
|
||||
- **Dynamical Systems**: Strogatz, S. (2015). *Nonlinear Dynamics and Chaos*
|
||||
- **Control Theory**: Åström, K. & Murray, R. (2008). *Feedback Systems*
|
||||
- **Statistical Inference**: Casella, G. & Berger, R. (2002). *Statistical Inference*
|
||||
- **Exponential Decay**: Standard mathematical function (e^(-λt))
|
||||
|
||||
### 8.2 Related Work
|
||||
|
||||
- **Trace-based JIT**: Bolz et al. (2009). "Tracing the Meta-Level: PyPy's Tracing JIT Compiler"
|
||||
- **Adaptive Systems**: Garlan et al. (2004). "Rainbow: Architecture-Based Self-Adaptation"
|
||||
- **Forth Optimization**: Ertl, M.A. (1996). "Stack Caching for Interpreters"
|
||||
|
||||
---
|
||||
|
||||
## IX. VERSION HISTORY
|
||||
|
||||
**v1.0** (2025-12-13):
|
||||
- Initial ontology, taxonomy, and lexicon
|
||||
- Formal mathematical definitions
|
||||
- Relationship diagrams
|
||||
- Usage guidelines
|
||||
|
||||
---
|
||||
|
||||
## X. ACKNOWLEDGMENTS
|
||||
|
||||
This ontology provides the formal conceptual framework for the StarForth project.
|
||||
It aims to eliminate ambiguity and enable precise academic discourse while
|
||||
acknowledging the metaphorical nature of certain conceptual mappings.
|
||||
|
||||
**License**: CC0 / Public Domain
|
||||
Reference in New Issue
Block a user