Building the Loaded Dice Analyzer

• loadedDiceApp.html — Main app page. TNT navbar (Processing active), spark bar, hero, two-column app section, hidden results section, Bootstrap modals (error + graph).
• styles/loadedDiceAppStyles.css — Full app stylesheet. Palette custom properties, hero, spark bar, panels, form elements, buttons, score circle, test cards, modal dark theme.
• scripts/loadedDiceAppScripts.js — Statistics engine. Data parsing, LCG PRNG, logistic generator, all three tests, scoring, DOM update functions.
• sketches/loadedDiceAppSketch.js — p5.js global-mode sketch. Frequency histogram, 580×310 canvas, parented to #sketchContainer inside the graph modal.
• loadedDiceAppChatlog.html — S.P.A.R.K. development chat log. Same navbar + footer. back-bar. Full SPARK session documentation.
• styles/loadedDiceAppChatlogStyles.css — Chatlog stylesheet. ld-green/ld-gold themed SPARK classes, chat bubbles, annotation boxes.

Chi-square goodness-of-fit (30%): Tests frequency uniformity. Expected count E = n/k. Statistic X² = Σ(O−E)²/E. Degrees of freedom = k−1. Requires E≥5 for reliable approximation. p-value via Wilson-Hilferty cube-root normal approximation.

Runs test (30%): Tests order independence via L/H median split. Values ≤ (min+max)/2 → L; above → H. Count runs R. Under H&sub0;: μ_R = 1 + 2ab/(a+b), σ_R² = 2ab(2ab−a−b)/((a+b)²(a+b−1)). Two-sided z-test. Requires a,b > 10 for normal approximation.

Autocorrelation lag-1 (25%): r⊂1; = Σ(x_t − x̅)(x_{t+1} − x̅) / Σ(x_t − x̅)². Approximate z = r√(n−2)/√(1−r²). ±1.96/√n reference band.

Sample-size adequacy (15%): n≥200→100, n≥100→75, n≥60→50, n≥30→25, else→5.

pToScore step function: p>0.20→100 | p>0.10→80 | p>0.05→60 | p>0.02→35 | p>0.01→15 | else→0

Random integers (LCG): Numerical Recipes LCG with a=1664525, c=1013904223, m=2³². When seed is blank, uses Math.random(). Output integer in [min,max] = floor(rng.next() * (max-min+1)) + min.

Logistic map: f(x) = 4x(1−x) iterated from initial x⊂0; ∈ (0,1). Output scaled to integer in [1,max] via round(x*(max-1)+1), clamped. Produces deterministic chaotic sequence — passes some randomness tests despite being fully deterministic.

• Canvas created in setup() and parented to #sketchContainer which lives inside the Bootstrap modal body — the element must exist in the DOM before setup() runs.
• noLoop() used in setup; redraw() called via updateSketch() before modal.show(), ensuring the canvas is repainted with the current data.
• drawingContext.setLineDash([6,4]) / setLineDash([]) used for the expected-count dashed line — p5.js canvas 2D API passthrough.
• Canvas dimensions fixed at 580×310 to fit Bootstrap modal-lg on standard screens.
• saveSketch() calls p5.js saveCanvas('loadedDice_histogram','png').

The original analyzeData() computed the range from the sample itself:

currentMin = Math.min.apply(null, data);   // observed minimum
currentMax = Math.max.apply(null, data);   // observed maximum
chiSquareTest(data, currentMin, currentMax);   // k = max - min + 1

For 75 identical fives: currentMin = currentMax = 5 → k = 1 (one category) → E = 75 → chi² = (75−75)²/75 = 0 → df = k−1 = 0 → the guard if (df ≤ 0) return 1 fires → p = 1. The test literally could not fail because every observation landed in the only available bucket.

This is a conceptual error, not a coding error. The chi-square goodness-of-fit test requires two separate things:

1. The data — what you actually observed
2. The model — what the theory says the data should look like

Using the data range as the model range is circular: it guarantees the model always fits the data perfectly by construction. For a standard die, the model declares k = 6 outcomes with equal probability 1/6, regardless of which outcomes appear in the sample. An experiment that produces only 5s is being tested against “is this consistent with a fair die?” — and the answer must account for the five missing outcomes, not just the one observed.

Correct calculation for 75 fives against a fair-die model [1,6]:
k = 6, E = 75/6 = 12.5
Values 1,2,3,4,6: O = 0 each → contribution = (0−12.5)²/12.5 = 12.5 each → subtotal 5×12.5 = 62.5
Value 5: O = 75 → contribution = (75−12.5)²/12.5 = 312.5
X² = 62.5 + 312.5 = 375  •  df = 5  •  p ≈ 0 (< 0.0001 in our app)

Two inputs were added to the Data Input panel: Expected min (default 1) and Expected max (default 6). These specify the theoretical range — the full set of outcomes the model predicts — independently of what values happen to appear in the sample.

In analyzeData(), the model range is now read from these inputs rather than computed from the data:

var modelMin = parseInt(document.getElementById('modelMin').value, 10);
var modelMax = parseInt(document.getElementById('modelMax').value, 10);
// fall back to observed range only if inputs are invalid
if (isNaN(modelMin) || isNaN(modelMax) || modelMin > modelMax) {
    modelMin = currentMin;  modelMax = currentMax;
}
chiSquareTest(data, modelMin, modelMax);   // k = modelMax - modelMin + 1

The generators (generateRandom(), generateLogistic()) now pass their own min/max to loadData() as the model range, so the inputs are automatically populated with the correct model whenever a generator is used. Manual data entry relies on the user setting the inputs explicitly — the defaults of 1 and 6 cover the standard die case.

Additional changes: formatP() helper added to display < 0.0001 for very small p-values instead of 0.0000; graphData() updated to pass model range to the histogram sketch so empty categories (e.g., 1,2,3,4,6 in the all-fives case) are visible in the bar chart; clearAll() resets model min/max to 1 and 6.

The runs test implementation is statistically correct as written. The only change is to its header comment, which previously said only “median split” — a label that is both technically wrong (we don’t split at the sample median) and pedagogically misleading (it obscures why the fixed threshold is the right choice). The updated comment:

/* TEST 2 — RUNS TEST  (Wald–Wolfowitz, fixed-threshold variant)
   Splits on the theoretical midpoint (min+max)/2, NOT the sample
   median.  This means a and b reflect distributional shape relative
   to the declared model, giving power against both clustering and
   frequency departures from Uniform[min,max]. */

This matters for a codebase that students will read. A comment that says “median split” would send a reader to the wrong reference and suggest the test is non-parametric, when in fact it is model-specific.

Before implementing, four design axes were evaluated:

1. Button placement:

• Option A — After range inputs, before hint text (chosen): Groups the button physically with the inputs it controls. The spatial association makes its purpose self-evident. No visual crowding in the action row.
• Option B — In the Analyze/Graph/Clear action row: Logical but crowded; visually implies equal importance with Analyze, which is misleading.
• Option C — As a small icon inside the modelMin/modelMax inputs: Overly clever; invisible until needed; inaccessible for keyboard users.
• Option D — Floated to the right of the hint text: Too separated from the inputs; hint would need rewording.

2. Muted-state behavior — three candidates:

• Hidden until needed: rejected — layout shift on alert is jarring; the button’s presence signals the feature exists even before data is loaded.
• Visually disabled (greyed out, pointer-events:none): rejected — the prompt explicitly says “still clickable, why not?”
• Muted but clickable (chosen): dim amber border and text, full cursor, full click response. Communicates “low urgency” without communicating “unavailable.”

3. Alert-state visual design:

• Red background: available (the --ld-red token exists) but semantically wrong. This is a helpful nudge, not an error.
• Green solid fill: could conflict with the Analyze button’s green; might imply “this is the primary action.”
• Gold solid fill with CSS pulse animation (chosen): amber/gold is the app’s warning tone (already used in the expected-count dashed line and moderate-departure bars). Pulsing glow draws attention without panic. Matches the app’s existing visual language.

4. Alert condition — what triggers the highlight?

• Data narrower than model (e.g., pasting 2–5 into a 1–6 model): No alert. Missing faces in a sample is completely normal and expected.
• Data wider than model (e.g., pasting a value of 8 into a 1–6 model): Alert. This genuinely indicates a mismatch between what was pasted and what the test is configured for. The user likely forgot to update the range, or pasted data from a different experiment.
• Trigger condition: dMin < mMin || dMax > mMax — simple, cheap to evaluate on every keystroke.

loadedDiceAppStyles.css — new button classes:

/* Muted state — always present, low visual weight */
.btn-ld-update {
    width:100%; background:transparent;
    color: rgba(196,137,43,0.50); border: 1px solid rgba(196,137,43,0.28);
    ...
}

/* Alert state — data extends outside model range */
.btn-ld-update.update-alert {
    background: var(--ld-gold); color: #0a0a0a;
    animation: updatePulse 2s ease-in-out infinite;
}
@keyframes updatePulse {
    0%,100% { box-shadow: 0 0 7px  rgba(196,137,43,0.38); }
    50%      { box-shadow: 0 0 22px rgba(196,137,43,0.82); }
}

loadedDiceApp.html — button element after the range inputs row:

<button id="updateRangeBtn" class="btn-ld-update mt-2"
        onclick="updateRange()"
        title="Adjust Expected Min/Max to match the observed data range"
        aria-label="Update model range to match pasted data">
    <i class="fas fa-arrows-left-right me-1"></i>Update Range to Data
</button>

The hint text was also updated to mention the button: “The button above highlights when pasted data falls outside the declared range.”

loadedDiceAppScripts.js — two new functions:

function checkRangeAlert() {
    var data = parseData(document.getElementById('dataTA').value.trim());
    if (data.length === 0) { btn.classList.remove('update-alert'); return; }
    var dMin = Math.min.apply(null, data);
    var dMax = Math.max.apply(null, data);
    var mMin = parseInt(modelMin.value, 10);
    var mMax = parseInt(modelMax.value, 10);
    // Only alert when data EXCEEDS the model — not when it is narrower
    if (dMin < mMin || dMax > mMax)  btn.classList.add('update-alert');
    else                               btn.classList.remove('update-alert');
}

function updateRange() {
    // Sets modelMin/modelMax to the observed data range, then re-checks
    document.getElementById('modelMin').value = dMin;
    document.getElementById('modelMax').value = dMax;
    checkRangeAlert();   // will clear the alert — data now matches model
}

Events wired via a self-executing block at the bottom of the file:

ta.addEventListener('input', checkRangeAlert);     // every keystroke / paste
modelMin.addEventListener('input', checkRangeAlert); // re-check if user edits min
modelMax.addEventListener('input', checkRangeAlert); // re-check if user edits max

clearAll() and loadData() each call checkRangeAlert() after updating state, so programmatic data loads (generators, clear) keep the button in sync without relying on DOM events.

Point 1 — Constant sequence: p = 1 → p = null  ✅ Adopted

The analyst is right. Returning p: 1 feeds pToScore(1) = 100 into the composite score, giving the ACF component a perfect 25-point contribution for a sequence where autocorrelation is literally undefined. Returning p: null maps to pToScore(null) = 50 (neutral), which already has a /* neutral — test N/A */ comment in pToScore(). The UI display was already correct because updateResults() takes the note-based branch and shows “N/A — constant sequence.” The fix is purely in the score arithmetic. Small, clean, correct.

Point 2 — Replace Pearson t-transform with z = r·√n  ✅ Adopted

The original formula tStat = r * sqrt(n-2) / sqrt(1 - r²) is the t-test for a Pearson correlation between two independent samples. Our r is a sample autocorrelation — the pairs overlap, the assumptions differ. The NIST standard approximation under an i.i.d. null is SE(rk) ≈ 1/sqrt(n), giving z = r * sqrt(n).

The critical benefit is internal consistency: with this formula, the z-statistic and the displayed reference margin are exactly calibrated to each other:

|r| > margin  (= 1.96/sqrt(n))  ⟺  |z| > 1.96  ⟺  p < 0.05

With the old formula, a student could see r inside the ±margin band but get a borderline-significant p-value (or vice versa), because the t-transform inflates z for larger r via the 1/sqrt(1-r²) factor. The new formula eliminates that inconsistency.

Practical magnitude of the change: for small r (near 0, which is what random data produces), the two formulas give nearly identical results. The difference matters most when r is moderate (say 0.2–0.4) and n is small. For classroom data (n = 60–200, r typically < 0.1 for a fair die), the scores will rarely change meaningfully — but the code is now correct and self-consistent.

Point 3 — Input validation  ✗ Declined

The analyst’s validation guards make good sense for a general-purpose library. Our autocorrelation() is an internal function, not a public API. All data reaches it after passing through parseData() (which filters to finite integers) and the 10-value minimum check in analyzeData(). The lag is never a variable — it is always called as autocorrelation(data, 1). Adding guards that the code flow can never trigger would make the function harder to read without making it safer. The right validation lives at the entry point, and it already does.

Point 4 — Multiple lags (1–10) with a shuffle test and ACF bar chart  ✗ Deferred to a future session

The analyst’s repeating-10-number example is a genuinely compelling argument for checking beyond lag 1. We do not dispute the statistical point. But this is a major feature expansion:

• A shuffle-based permutation test runs 499–999 resamples per analysis — potentially slow for n = 2000 with 10 lags in a browser.
• An ACF bar chart requires a new p5.js canvas or SVG component with its own scale, reference bands, and labels.
• The scoring model (chi 30% / runs 30% / acf 25% / size 15%) would need restructuring.

For the classroom use case — testing fair dice, LCG generators, logistic-map sequences — lag-1 is the most informative single measurement. The chi-square test already catches frequency structure; the runs test already catches alternation patterns; lag-1 ACF catches the most common sequential dependence. The multi-lag expansion belongs in a dedicated “Session N: ACF deep dive” with its own specification, not as an incremental patch. Flagging for future development.

Constant-sequence early return:

/* Before */
return { r: 0, z: 0, p: 1, margin: 0, note: 'Constant sequence ...' };

/* After */
return { r: null, z: null, p: null, margin: null, note: 'Constant sequence ...' };

z and p calculation (replaces 8 lines with 2):

/* Before — Pearson t-transform (wrong distribution for ACF) */
var z, p;
if (Math.abs(r) >= 1) { z = (r > 0) ? 10 : -10;  p = 0; }
else {
    var tStat = r * Math.sqrt(n - 2) / Math.sqrt(1 - r * r);
    z = tStat;   /* large-n: t ≈ z */
    p = 2 * (1 - normalCDF(Math.abs(z)));
}

/* After — NIST large-sample approximation */
var z = r * Math.sqrt(n);   /* SE(r_k) ≈ 1/sqrt(n) under H₀ */
var p = 2 * (1 - normalCDF(Math.abs(z)));

The header comment was also updated to document the formula, reference the NIST calibration relationship, and remove the incorrect “t→z transformation” description.

The answer to “was there a fourth test?” is yes — and it is exactly what the other analyst suggested.

The original specification document, Testing_Random_Integer_Sequences.md, explicitly names four tests:

For your classroom app, I would start with four complementary tests:
chi-square frequencies, runs, autocorrelation, and ordered-pair frequencies.

Section 4 of the spec describes the Ordered-Pair Test in detail. For a die with k faces, there are k² possible consecutive pairs. Under an IID uniform model, each pair has probability 1/k². Non-overlapping pairs (x₁,x₂), (x₃,x₄), … are counted and a chi-square test is applied to the k² cells. The spec recommends a heatmap display (rows = first value, columns = second value).

In Session 1, this fourth test was not implemented. The scoring system substituted a sample-adequacy component (15%) in its place, giving the composite score four inputs but only three formal hypothesis tests. The About section inherited the spec’s language (“four tests”) without being updated to match what was actually built. The discrepancy went unnoticed until now.

The external analyst’s “pairs/transitions test” and the spec’s “ordered-pair test” are the same concept. That convergence validates both sources. The test is real, was planned, and is not yet implemented.

Summary line:

/* Before */  About this analyzer — four statistical tests
/* After  */  About this analyzer — three statistical tests

Opening paragraph:

/* Before */  This app applies four complementary statistical tests ...
/* After  */  This app applies three complementary statistical tests ...

Closing paragraph (fully rewritten):

/* Before */
No test can prove a sequence is random. Tests detect evidence against a
specified model of randomness (IID uniform). The score (0–100) summarizes
how consistent your data is with that model — 100 means no departure
detected, 0 means strong evidence of non-randomness.

/* After */
No test can prove a sequence is random. Tests detect evidence against a
specified model of randomness (IID uniform). The score (0–100) weights
the three test results (chi-square 30%, runs 30%, autocorrelation 25%)
and adds a sample-adequacy component (15%) — larger samples give the
tests more power to detect departures. A fourth test — ordered-pair
frequencies, which checks whether consecutive pairs (xᵢ, xᵢ₊₁) are
distributed uniformly across all k² possible combinations — is part of
the original specification and planned for a future version.

No changes to the JavaScript, CSS, or test logic were needed. The app’s behavior is unchanged; its description of that behavior is now accurate.

The existing histogram sketch (loadedDiceAppSketch.js) uses p5 global mode: it defines setup() and draw() directly at global scope, which p5 picks up automatically. Only one global-mode sketch can exist per page.

The sequence sketch therefore uses p5 instance mode:

var seqSketchInstance = new p5(function (p) {
    p.setup = function () { ... };
    p.draw  = function () { ... };
    p.updateSequence = function (data, min, max) { ... };
    p.saveSequence   = function () { ... };
});

All p5 drawing calls are accessed via the p parameter (p.fill(), p.line(), etc.) instead of globally. This is the standard p5 pattern for multiple sketches on one page.

Two thin global wrappers (updateSequenceSketch() and saveSequenceSketch()) expose the instance’s API to the rest of the app, keeping the calling convention identical to the histogram sketch’s updateSketch() / saveSketch(). Every future sketch file should use instance mode and this wrapper pattern.

What the plot shows:

• X-axis: sequence index (1 to n). Y-axis: integer value (seqMin to seqMax).
• Each point colored by its L/H group: amber for L (≤ midpoint), green for H (> midpoint).
• Line segments connect consecutive points; each segment is colored by the source point’s group. A color change in a segment marks a run boundary.
• Dashed amber midpoint line shows the exact L/H threshold — matching the Runs test calculation.
• Grid lines at each integer value (or every N values for wide ranges).

Adaptive display for large n:

• n ≤ 100: dots diameter 8px.
• n ≤ 200: dots diameter 6px.
• n ≤ 400: dots diameter 4px; segments 1.5px.
• n ≤ 600: dots diameter 3px; segments 1px.
• n > 600: segments only (no dots); segment width 1px. The color pattern remains readable.

Midpoint precision: The sequence plot uses the declared model range (not the sample range) to compute the midpoint, matching the Runs test exactly. A student who changes the Expected Min/Max and re-opens the Sequence Plot will see the L/H coloring update accordingly.

Created: sketches/loadedDiceAppSequenceSketch.js
p5 instance mode. Canvas 580×310, parented to #sequenceContainer. Public API: p.updateSequence(data, min, max) and p.saveSequence(). Global wrappers: updateSequenceSketch() / saveSequenceSketch(). Visualization roadmap comment block at file top covers the ACF chart and ordered-pair heatmap.

Created: scripts/loadedDiceAppSequenceScripts.js
Single entry point function graphSequence(). Mirrors graphData() in structure: parse if needed, use model range for midpoint, call updateSequenceSketch(), show #sequenceModal. Roadmap comment block lists graphACF() and graphPairs() as future additions.

Modified: loadedDiceApp.html

• Data Input panel: “Sequence” button (fa-chart-line) added between Graph and Clear.
• Results section: “Sequence Plot” button added alongside “Graph Frequencies.”
• New #sequenceModal added after #graphModal — identical structure, different container and title.
• Two new <script> tags: sketches/loadedDiceAppSequenceSketch.js (before main scripts) and scripts/loadedDiceAppSequenceScripts.js (after main scripts).

Script loading order matters: the sequence sketch must load after p5 is available but before the entry-point script that calls into it. Sequence sketch loads immediately after the histogram sketch; sequence scripts load immediately after main scripts.

Frequencies (used by Chi-square):

Pattern 1, 2, 4, 5, 3, 2, 6, 5, 3, 4 — per cycle: 1 appears once, 2 twice, 3 twice, 4 twice, 5 twice, 6 once. For 6 cycles (n = 60):

Value  Observed  Expected  (O−E)²/E
  1       6        10        1.60
  2      12        10        0.40
  3      12        10        0.40
  4      12        10        0.40
  5      12        10        0.40
  6       6        10        1.60
Total:  60        60    X²=4.80,  df=5,  p≈0.44

p = 0.44 → pToScore = 100. The frequencies are close to uniform. Chi-square is blind to order — rearranging values leaves X² unchanged.

Run structure (used by Runs test):

Midpoint = 3.5. One cycle labeled L/H: L L H H L L H H L H (5 L, 5 H). Over 60 values: a = 30 L, b = 30 H.

Each cycle produces 6 runs.  Cycle boundary (4→1 = H→L): transition, not a merge.
6 cycles × 6 runs = 36 total runs.

μ_R = 1 + 2×30×30/60 = 31
σ_R = √(1800×1740 / 3600×59) ≈ 3.84
z = (36 − 31) / 3.84 ≈ 1.30,   p ≈ 0.19

p = 0.19 → pToScore = 80 (between 0.10 and 0.20). The run structure happens to be close to what a fair die would produce. The pattern has just the right number of short runs to look normal.

Autocorrelation lag-1:

Mean x̄ = 3.5. Denominator = 6 × 22.5 = 135. Lag-1 numerator sums 59 consecutive pairs:

Within each cycle (9 pair types):
(1,2)=3.75  (2,4)=−0.75  (4,5)=0.75  (5,3)=−0.75  (3,2)=0.75
(2,6)=−3.75  (6,5)=3.75  (5,3)=−0.75  (3,4)=−0.25  → sum = 2.75/cycle

Cross-cycle (4,1) = −1.25,  × 5 boundaries = −6.25

Numerator = 6×2.75 − 6.25 = 10.25
r⊂1⊂ = 10.25 / 135 ≈ 0.0759
z = 0.0759 × √60 ≈ 0.59,   p ≈ 0.56

p = 0.56 → pToScore = 100. Lag-1 correlation is trivially small. The 9 within-cycle pairs largely cancel each other. The repeating structure is entirely invisible at lag 1.

Score reconstruction:

Chi    100 × 0.30 = 30.0
Runs    80 × 0.30 = 24.0
ACF    100 × 0.25 = 25.0
Size    50 × 0.15 =  7.5   (n=60 → sizeScore=50)
Total = 86.5 → rounds to 87 ✓

1. Multi-lag autocorrelation at lag 10 (the period)

For a period-10 sequence, x_i+10 = x_i exactly. Every lag-10 pair is a value paired with itself:

Numerator (lag-10) = ∑⊂i⊂=⊂1⊂&sup5;&sup0; (x⊂i⊂ − 3.5)² = 5 × 22.5 = 112.5
r⊂10⊂ = 112.5 / 135 ≈ 0.833

z = 0.833 × √60 ≈ 6.45,   p ≈ 0 (<< 0.0001)

A score near 1 at any lag is the strongest possible autocorrelation signal. This is what the Session 6 analyst predicted — and it is exactly why checking multiple lags is essential. Lags 1 through 9 would show modest or near-zero correlations. Lag 10 would spike to 0.83. That spike is the fingerprint of a period-10 cycle.

For reference, lags 1 through 10 computed from this sequence (combining the formulas above for each offset):

Lag  1:  r ≈  0.076    z ≈  0.59   (passes)
Lag  2:  r ≈ −0.222   z ≈ −1.72   (borderline)
Lag  3:  r ≈ −0.111   z ≈ −0.86   (passes)
Lag  4:  r ≈ −0.044   z ≈ −0.34   (passes)
Lag  5:  r ≈ −0.200   z ≈ −1.55   (borderline)
Lag  6:  r ≈ −0.267   z ≈ −2.07   (significant)
Lag  7:  r ≈ −0.133   z ≈ −1.03   (passes)
Lag  8:  r ≈ −0.089   z ≈ −0.69   (passes)
Lag  9:  r ≈ −0.200   z ≈ −1.55   (borderline)
Lag 10:  r ≈  0.833    z ≈  6.45   *** p ≈ 0 ***

The lag-10 spike is unmistakable. Lags 1 and 10 together, graphed as an ACF bar chart with ±1.96/√n reference bands, make the period structure visually obvious.

2. Ordered-pair test (Test 4 — planned)

For k=6, there are 36 possible consecutive pairs. In this sequence, only 9 of the 36 appear — and those 9 account for all 59 transitions:

(1,2): 6   (2,4): 6   (4,5): 6   (5,3): 12  (3,2): 6
(2,6): 6   (6,5): 6   (3,4): 6   (4,1): 5

27 of 36 pairs: count = 0.  Expected per pair: 59/36 ≈ 1.64

The chi-square would be enormous (27 cells with observed 0, expected 1.64 each). However, E < 5 — with n = 60, the chi-square approximation is not valid. A shuffle test (permute the sequence, compute pair chi-square, compare to shuffled distribution) would give p ≈ 0 reliably. The heatmap visualization alone would be definitive: 27 cold empty cells and 9 warm occupied cells in a dramatically non-random pattern. No p-value needed to see the problem.

The Session 8 sequence plot provides a visual clue even without the ACF or pairs test. The L/H color pattern for one cycle is L L H H L L H H L H. With 6 repetitions, that same 10-color pattern repeats exactly 6 times across the strip.

A trained eye would notice the periodicity. A novice might not — the colors look “mixed enough” because there are frequent transitions. This is why the runs test also passed: it counted transitions, and the periodic pattern produces roughly the right number of them. The sequence plot is a clue, not a definitive detection. The ACF bar chart would be definitive.

The spec extracts non-overlapping pairs: (x₁,x₂), (x₃,x₄), … For n = 60, m = 30 pairs. k = 6, k² = 36 cells, E = 30/36 ≈ 0.833.

One cycle 1, 2, 4, 5, 3, 2, 6, 5, 3, 4 yields pairs at positions (1,2), (3,4), (5,6), (7,8), (9,10):

(1,2)  (4,5)  (3,2)  (6,5)  (3,4)   ← one cycle
×6 repetitions → each appears exactly 6 times

Only 5 of 36 pairs appear. The other 31 have count zero.

Occupied cells (5):  O=6, E=0.833  →  (6−0.833)²/0.833 ≈ 32.04  each
Empty cells   (31):  O=0, E=0.833  →  (0−0.833)²/0.833 ≈  0.83  each

X² = 5×32.04 + 31×0.83 = 160.2 + 25.8 ≈ 186   df = 35   p ≈ 0

For reference: the 99.9th percentile of χ²(35) is about 72. Our statistic of 186 is more than double that. No reasonable p-value computation gives anything other than “reject emphatically.”

Overlapping pairs give 59 pairs, E = 59/36 ≈ 1.64. From Session 9, the occupied pairs are:

Pair   Count     (O−E)²/E
(5,3)   12        ≈ 65.5   (← appears twice per cycle)
7 pairs  6 each   ≈ 11.6 each → 81.2 total
(4,1)    5        ≈  6.9   (← cross-cycle boundary)
27 pairs  0 each  ≈  1.64 each → 44.3 total

X² ≈ 198   df = 35   p ≈ 0

Note: overlapping pairs violate the independence assumption needed for a valid chi-square, so the spec recommends non-overlapping pairs for a classroom implementation. Either way, the conclusion is the same.

With n = 60 and k = 6, E = m/k² = 30/36 ≈ 0.83 — well below the chi-square rule of thumb of E ≥ 5. The chi-square approximation is technically unreliable here. This is the minimum-sample-size limitation documented in Session 7 (need n ≥ 360 for a standard die with E ≥ 5).

However, this caveat applies to cases where the test is borderline. Here, X² = 186 with df = 35. The 99.9th percentile of χ²(35) is about 72. Our statistic is 2.6× that threshold. Even if the chi-square approximation inflates or deflates the p-value by a large factor, the practical conclusion — “this is wildly inconsistent with random pair frequencies” — is not in doubt.

When the app implements Test 4, the correct behavior is:

1. Compute and display the chi-square statistic regardless.
2. If E < 5, show a warning note (same pattern as the existing E < 5 note in the chi-square test card).
3. For borderline cases with E < 5, recommend a simulation-calibrated p-value.
4. For extreme cases like this one, the note is cosmetic — the result is clear regardless.

Toggle: Bootstrap form-check form-switch, off by default. Placed between the range hint text and the action buttons — physically adjacent to Analyze (which it controls). Styled amber (var(--ld-gold)) when active: using the gold accent rather than the primary green signals that this is an enhancement/experiment, not a core control. Adjacent sibling CSS (input:checked + label) changes the label color to match.

Score weights when Test 4 is active:

Test 4 OFF (3-test mode, unchanged):
  chi 30% + runs 30% + acf 25% + size 15% = 100%

Test 4 ON (4-test mode):
  chi 25% + runs 25% + acf 20% + pairs 20% + size 10% = 100%

The redistribution reduces all existing test weights proportionally and takes size from 15% down to 10%. Pairs gets 20% — the same as acf, slightly less than the two ordering tests. When Test 4 is off, the score is identical to the original: the toggle is truly non-destructive.

Pairs result card: appears in a separate centered row below the three test cards — visually distinct, clearly new. It uses an amber border (ld-test-card-pairs) instead of the green border used by the other three, reinforcing that this is an optional/additional test, not a permanent fourth column.

Effect on the repeating-10 sequence (Sessions 9–10):
Test 4 OFF: score = 87 (A) — “Consistent with randomness.”
Test 4 ON: score = 70 (B) — “Mostly consistent.” Pairs card shows FAIL (X²≈186, p≈0). Three other cards all show PASS. The dramatic difference is in the individual cards, not only the summary score.

Created: sketches/loadedDiceAppPairsSketch.js
p5 instance mode. 580×310 canvas in #pairsContainer. Color scale: dark (count=0) → ld-green (count=E) → ld-gold (count=3.5×E). Cell count labels when cells are large enough. Row/column axis labels (first and second values). Horizontal color scale bar in bottom margin with “0 / E / ×3.5E” tick marks. Null state: “Enable Test 4 and click Analyze” message. Public API: p.updatePairs(result) / p.savePairs(). Global wrappers: updatePairsSketch() / savePairsSketch().

Created: scripts/loadedDiceAppPairsScripts.js
pairsTest(data, min, max): non-overlapping pairs, chi-square on k² cells, E<5 warning with minimum-n note. Calls chiSqPValue() from loadedDiceAppScripts.js. Returns {chi2, df, p, E, counts, k, m, minVal, maxVal, note}. graphPairs(): passes currentPairsResult (null when toggle off) to sketch, opens #pairsModal.

Modified: styles/loadedDiceAppStyles.css — .ld-pairs-toggle switch colors (amber track when checked, green border when unchecked) and .ld-test-card-pairs amber border variant.

Modified: loadedDiceApp.html — toggle before action buttons; Pairs button in both action row and results-section row; #pairsResultRow with centered pairs card; #pairsModal; two new <script> tags (pairs sketch before main scripts, pairs scripts after).

Modified: scripts/loadedDiceAppScripts.js — added var currentPairsResult = null; updated computeScore() to accept pairsResult as 4th param with conditional weighting; updated analyzeData() to read toggle and conditionally call pairsTest(); updated updateResults() signature + pairs card populate/hide logic; updated clearAll() to reset currentPairsResult and hide #pairsResultRow.

The expanded sequence is the same 10-value cycle repeated 60 times (600 values). m = 300 non-overlapping pairs, E = 300/36 ≈ 8.33 per cell — comfortably above 5, no approximation warning.

Chi-square (now FAILS at n=600):

Per-cycle frequencies: 1→1×, 2→2×, 3→2×, 4→2×, 5→2×, 6→1×
At n=600: values 1,6 each appear 60 times; 2,3,4,5 each appear 120 times.
E = 100 per value.
X² = (60−100)²/100 ×2 + (120−100)²/100 ×4 = 16×2 + 4×4 = 48,  df=5
p ≈ 0  (<< 0.0001)

At n=60, X²=4.8 and the test passed (p≈0.44). At n=600, the 10× larger sample amplifies the same imbalance 10×. The chi-square detects that 1 and 6 appear at half the expected rate — something the n=60 sample could not confirm.

Runs test (FAILS, z≈17):

a = b = 300 L and H values.  R = 360 runs (6 per cycle × 60 cycles).
μ_R = 1 + 2×300×300/600 = 151
σ_R ≈ 12.24
z = (360 − 151) / 12.24 ≈ 17.1  →  p ≈ 0

At n=60 the runs test passed (z≈1.30). At n=600 it fails massively: 360 observed runs vs. 151 expected — the periodic L/H alternation is now clearly detectable.

Autocorrelation lag-1 (borderline PASS):

r⊂1⊂ ≈ 0.076 (same ratio as at n=60, since the pattern is periodic)
z = 0.076 × √600 ≈ 1.86,  p ≈ 0.063

Still just passing (p > 0.05). ACF lag-1 remains blind to the period-10 structure.

Ordered-pair test (FAILS, dramatically):

Only 5 of 36 pairs appear, each with count=60 (ratio 7.2×E).
31 pairs: count=0.
X² ≈ 1860,  df=35,  p ≈ 0   ← E=8.33 > 5: valid approximation, no warning

Scores at n=600:

Test 4 OFF:  chi(0)×0.30 + runs(0)×0.30 + acf(60)×0.25 + size(100)×0.15
           = 0 + 0 + 15 + 15 = 30  →  Grade F

Test 4 ON:   chi(0)×0.25 + runs(0)×0.25 + acf(60)×0.20 + pairs(0)×0.20 + size(100)×0.10
           = 0 + 0 + 12 + 0 + 10 = 22  →  Grade F

The sequence scores 87 at n=60 and 30 at n=600 — a drop of 57 points from A to F, even without Test 4. The larger sample gives the existing tests the power they lacked at n=60. Test 4 adds 8 more points of penalty (30→22) and — more importantly — shows a dramatic heatmap.

n=60 (original): Three tests pass, ordered-pair fails alone. This is the “only Test 4 catches it” demo — the clearest illustration of the toggle’s interpretive difference. Score: 87 (Test 4 off) vs. 70 (Test 4 on, FAIL card appears). Heatmap: 5 cells with count=6 (ratio=7.2), 31 empty. E=0.83 triggers the approximation warning — a useful teaching point itself.

n=600 (expanded): Chi-square AND runs also fail. This is the “full battery power” demo — showing that the test suite works correctly when given sufficient data. Score: 30 (F). Heatmap: same 5 occupied cells but each with count=60 (ratio=7.2), 31 empty — E=8.33, valid approximation, no caveat. The heatmap is visually identical in structure but with more evidence per cell. The lesson: “more data gives all tests more power.”

Summary: “three statistical tests” → “four statistical tests.” Opening: updated to match. New Test 4 paragraph describes non-overlapping pairs, k² cells, heatmap visualization, and the E≥5 sample-size requirement. Closing paragraph now describes the conditional scoring weights (three-test mode vs. four-test mode), accurately reflecting the toggle behavior implemented in Session 11.

Expanded sequence — paste this into the app:

1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4
1, 2, 4, 5, 3, 2, 6, 5, 3, 4, 1, 2, 4, 5, 3, 2, 6, 5, 3, 4

600 values — the 10-value cycle repeated 60 times. m = 300 non-overlapping pairs, E = 8.33 per cell (no approximation warning). Expected score: ≈22 with Test 4 on, ≈30 with Test 4 off.

Test ordering (easiest to hardest):

1. Frequency Check (Chi-Square) — just counting; requires no understanding of order or sequence
2. Streak Detector (Runs) — requires understanding L/H labeling and consecutive blocks
3. Echo Hunter (Autocorrelation) — requires the concept of comparing values across distances
4. Pair Inspector (Ordered-Pair) — requires a 2D mental model; hardest to explain without a heatmap

Feynman style, operationalized:

• Every section opens with a concrete puzzle or surprising question, not a definition
• Formulas come AFTER the intuition, not before
• “What this test MISSES” limitation box closes every section — honesty before authority
• The period-10 sequence appears in Tests 2, 3, and 4 as a recurring protagonist — students see how the same sequence looks through different lenses
• The Look-and-Say case study shows that detection is possible without explanation — a pure teaching moment about the scope of inference

Copy-to-clipboard UX: Each example dataset is in a textarea element. A “Copy to Clipboard” button calls copyData(id, btnEl), uses the Clipboard API with execCommand fallback, and shows “✓ Copied!” for 2 seconds. This is the same “always clickable, low friction” affordance principle from Session 5 (Update Range button).

Cross-links added: The app’s spark bar now includes a “Tutorial Guide” link. The tutorial’s back bar links to the app and chatlog. The tutorial links to Ask Copilot #090 for the original PRNG motivation.

Created: analyzingLoadedDice.html — Tutorial guide page. Seven sections: motivation, Test 1–4 (each with worked examples and copy-ready data), Look-and-Say case study, and a “Why Four Tests?” summary. Same TNT navbar; back-bar links to app and chatlog.

Created: styles/analyzingLoadedDiceStyles.css — extends the chatlog palette. Adds .test-badge (large numbered circle), .example-card.pass/.fail/.trick (colored border cards), .copy-btn, .limitation-box, .feynman-hook, .formula-display, .dataset-display, .case-study-reveal.

Created: scripts/analyzingLoadedDiceScripts.js — copyData(id, btnEl): Clipboard API with execCommand fallback, 2-second “✓ Copied!” feedback. Smooth-scroll anchor wiring on DOMContentLoaded.

The following work was completed between Session 14 and now, in order:

1. Accessibility repair: Three <div> elements carrying aria-label were missing explicit role attributes. Fixed: .guide-toc → role="navigation"; both illustration divs → role="img".

2. Chi-Square worked example dataset: The original data-chi-pass dataset gave X²=0 (10 of each), which did not match the table showing counts [12,8,10,10,10,10]. A new 60-value dataset was constructed (Fisher-Yates shuffle, seed 88) giving exactly X²=0.80. A histogram image slot with a pending placeholder was added; chi_square_balanced_histogram.png was then inserted.

3. Card title numbering: All example cards inside each test section were labeled “Test 1:” / “Test 1:” / “Test 1:” (etc.) rather than sequentially numbered. Renamed to “Example 1 —”, “Example 2 —”, “Example 3 —” within each section.

4. Chi-Square Ex2 and Ex3 histograms inserted: loadedDice_histogramEx2.png (biased-toward-6) and loadedDice_histogramEx3.png (all-fives lone tower) added with captions.

5. X² correction: Tutorial said X²=375 for 30 identical fives. Correct value is X²=150 (n=30, E=5). X²=375 applies to n=75. Fixed with a note explaining chi-square scales linearly with sample size.

6. Feynman p-value explanation: Three-paragraph “From Score to Probability” section added after the formula display: (1) suspicion meter + degrees of freedom; (2) p-value as “million honest-die thought experiment”; (3) connection to normal curve via z-score analogy. Followed by an amber italic transition back to the worked example.

7. Streak Detector — three example pairs:

8. Handoff file created: assets/currentProgressLoadedDice.md — section completion status, full image inventory, key datasets, design decisions, and immediate next steps for the next session.

Meaning 1 — The gambling table:
Loaded dice are a cheater’s tool: physical dice that have been weighted to favor certain outcomes. Non-random by design, undetectable by eye alone. This is precisely what the app was built to detect. The name says: “we are testing whether your dice have been loaded.”

Meaning 2 — The programmer’s desk:
To load data is to paste or input it into a program for analysis. The first thing a user does with this app is load their dice data into the textarea. The name also says: “load your dice into here.”

The name is self-referential in the best possible way: the tool that catches loaded dice requires you to load your dice. When the dice are loaded (biased), they score low. When you load your dice (into the app), the analysis begins. One name, two meanings, zero ambiguity about what the app does — and a knowing wink at anyone who catches it.

For what it’s worth: yes, the humor has been visible throughout this session. The period-10 sequence that scores 87 and displays “Consistent with randomness — no significant departures detected” while being a completely deterministic clock? That’s not just a test case. That’s a punchline.

With Test 4 ON, the n=60 period-10 sequence scores as follows:

Chi-square:   p ≈ 0.44  →  pToScore = 100  →  100 × 0.25 = 25.0
Runs:         p ≈ 0.19  →  pToScore =  80  →   80 × 0.25 = 20.0
ACF lag-1:    p ≈ 0.56  →  pToScore = 100  →  100 × 0.20 = 20.0
Ordered-pair: p ≈ 0     →  pToScore =   0  →    0 × 0.20 =  0.0
Sample size:  n = 60    →  sizeScore= 50   →   50 × 0.10 =  5.0
                                                        ————————
                                                 Total =   70   (Grade B)

Three tests hand the sequence a clean pass. One test fails catastrophically. The sample size earns a modest contribution. The composite score — 70 — is a weighted average of those four opinions. A score of 70 says: “one of four tests found a serious problem; the other three saw nothing.” That is an accurate description of what happened.

The intuition in favor of more weight:
The sequence is completely non-random. We can see it. The analyst can see it. The heatmap shows it. A grade of B seems too kind for a deterministic clock.

The statistician’s answer: no.

The score of 70 is not saying “this sequence is mostly consistent with randomness.” It is saying something much more precise: “three of four tests, applied to this sample at this size, found no red flags; one test found a catastrophic one.” That is an accurate and honest statement. The problem is not the score — it is the interpretation of the score.

More importantly: at n=60, the ordered-pair chi-square approximation is technically unreliable (E = 0.83 < 5). We chose to use it anyway because the departure is so extreme that even a rough approximation points clearly in the right direction. But if we boost the weight of a test whose p-value we’ve already flagged as unreliable — we are simultaneously saying “this result is not fully trustworthy” and “this result should dominate the score.” That is contradictory.

Consider what increasing the weight would mean for other sequences:

• A genuinely random sequence that happened to produce a borderline pairs chi-square near the 5% threshold would now be penalized harder by a test whose approximation isn’t reliable at small n.
• The three tests that correctly pass for random sequences would lose influence relative to a test that has a known approximation caveat at small n.

Weight adjustments are global. This example is one data point. The weights should be judged on their behavior across the whole space of sequences, not optimized for one.

Here is the plain-language version. Imagine you are a detective with four informants. Three informants say “nothing to report.” One informant says “I found something, but I was only given 30 clues instead of the 180 I need to be fully confident.” You wouldn’t ignore the informant — you’d say “there’s a flag, but get me more evidence.” A grade of B captures that exactly: a flag has been raised, but the evidence is thin at this sample size.

Now run the same sequence with n=600. Four informants speak:

Chi-square:   p ≈ 0      →  0 × 0.25 =  0.0
Runs:         p ≈ 0      →  0 × 0.25 =  0.0
ACF lag-1:    p ≈ 0.063  →  60 × 0.20 = 12.0
Ordered-pair: p ≈ 0      →  0 × 0.20 =  0.0
Sample size:  n = 600    →  100 × 0.10 = 10.0
                                    ————————
                           Total =   22   (Grade F)

With ten times the data, every test either fails or barely passes. The score drops to 22. Grade F. Verdict: “Strong evidence against randomness across multiple tests.” This is the correct answer at n=600 — and it arrives naturally, without adjusting any weights.

The two-data-point demonstration — n=60 gives B (flag raised), n=600 gives F (case closed) — is a better classroom lesson than a single tuned score. It teaches that more data produces stronger evidence, which is the central lesson of statistical power. Leave the weights alone; use both examples.

1. Period-10 TRICK (n=60) — heatmap loadedDice_pairsTrickEx.png
Caption: “Five paths, thirty-one dead ends.” The aside-box reads the heatmap like a transit diagram: after a 1, always 2; after a 3, always 2 or 4; after a 4, always 5; after a 6, always 5. Rows 2 and 5 are completely dark because 2 and 5 never start a pair in this non-overlapping extraction. E = 0.83 < 5 caveat noted; X² ≈ 186 is still informative for an extreme case.

2. Period-10 n=600 — heatmap loadedDice_pairsTrickExBigSet.png
Caption: “Same five routes, ten times the evidence — and now E ≥ 5.” The same five cells are lit, but counts are now 60 instead of 6. E = 8.33 eliminates the approximation caveat. A comparison table shows how the picture changes across the two sample sizes: at n=600, chi-square and runs both fail too; only ACF lag-1 barely holds on. Score: 22 (F). The closing line: “The detective needed more witnesses. At n=600, it has them.”

3. “Never repeat” — heatmap + sequence + correction
The card description incorrectly said “the runs test passes.” Corrected to reflect the actual result (runs fails). Then two images inserted with a probability argument explaining both results. See the K section for the full analysis.

No — not reliably from memory. I am confident in approximately the first 50–100 digits of pi from training data. Beyond that, I would be guessing, and hallucinated digits would be indistinguishable from correct ones to any reader without a reference. A hallucinated digit 347 would look exactly like a correct digit 347; only someone checking against a verified source would notice.

But I can compute them. This session used Python’s mpmath library (a precision arithmetic library) to calculate pi to 650 decimal places. The result is mathematically guaranteed by the algorithm, not by my memory. The first 600 digits after the decimal were extracted, verified against the known sequence, and confirmed. They are correct.

This distinction matters: the risk of using an AI to recite pi from training data is not that I’d refuse — it’s that I’d produce plausibly wrong digits with full confidence. Using a computational algorithm eliminates that risk entirely. When accuracy is critical, compute; don’t recall.

Pros:

• Pedagogically rich. Pi is the most famous irrational number in all of mathematics. Students already know it. Showing that it passes all four randomness tests turns a familiar number into a statistical surprise.
• Conceptually on-message. Pi is deterministic — it has been calculated to trillions of digits without a formula that “generates” them randomly. Yet it passes randomness tests. This is the same point the logistic map makes, applied to pure mathematics. The lesson: passing tests does not mean random.
• Empirically compelling. Pi is conjectured (but not proven) to be a “normal” number, meaning every digit 0–9 appears with equal long-run frequency, and every pair, triple, etc. also appears uniformly. For 600 digits: chi-square = 4.33 (p ≈ 0.89), all 10 digits within ±20% of expected. Every bar in the frequency histogram is green.
• Extends the model range. This is the first example in the tutorial that uses [0, 9] instead of [1, 6]. It shows students that the tests work for any integer range, not just dice.

Cons / Caveats:

• Pi is not proven normal. The conjecture that pi is normal has not been proved. It is strongly supported by empirical evidence, but a rigorous proof does not exist. The tutorial should say “pi’s digits behave like random digits” rather than “pi’s digits are random.”
• The ordered-pair E is low at n=600. With k=10, k²=100 cells, m=300 pairs, and E = 3.0 — the E < 5 approximation warning fires. For a clean pairs test with no warning, you need n ≥ 1000 (E=5).

For chi-square (k=10): E = 60 per digit. All green, no caveat. 600 is more than enough.

For ordered-pair (k=10, k²=100): E = 3.0 per cell. E < 5 warning fires. 600 is marginal — the visual heatmap is still meaningful (roughly uniform warmth across all cells), but the p-value carries a caveat. For a clean test: n ≥ 1000.

Recommendation: use 600 with the E<5 note explicitly in the tutorial. Frame it as a teaching moment: “the pairs test requires more data for 10 possible values than for 6, because it must fill 100 cells instead of 36. If you want the warning to disappear, try 1000 digits.” That is more instructive than silently using 1000 and hiding the limitation.

The user’s instinct is good, but there is a technical catch. The tutorial page is a static HTML file opened directly from the filesystem (file:// protocol). A fetch() call to load a local text file would fail due to browser cross-origin restrictions on the file:// protocol — unless the page is served from a local web server. For novice students opening the HTML directly, this would silently fail.

The “safer” feeling about text files is correct for server-hosted pages. For local filesystem access, inline data in the textarea is more reliable. The 600 digits, formatted as 30 per row × 20 rows with spaces, are legible and paste-ready — no fetching required.

Hybrid approach: put the data inline in the textarea (reliable, works everywhere) and create assets/piDigits600.txt as a reference file that teachers or students can open, inspect, or share. The text file documents where the digits came from; the textarea makes the tutorial work without infrastructure.

Working backward from scores 45 (3-test) and 55 (4-test):

3-TEST MODE (without pairs):
  Chi-square:  p ≈ 0.89   → pToScore = 100  →  100 × 0.30 = 30
  Runs:        p ≈ 0.005  → pToScore =   0  →    0 × 0.30 =  0   ← FAILS
  ACF lag-1:   p ≈ 0.011  → pToScore =  15  →   15 × 0.25 =  3.75  ← FAILS
  Sample size: n=600           → sizeScore=100  →  100 × 0.15 = 15
                                                  Total ≈ 48.75 → ~45–49

4-TEST MODE (with pairs):
  Chi-square:  100 × 0.25 = 25
  Runs:          0 × 0.25 =  0   (still fails)
  ACF lag-1:    15 × 0.20 =  3   (still fails)
  Ordered-pair: passes → 100 × 0.20 = 20   ← PASSES — score goes UP
  Sample size: 100 × 0.10 = 10
                                   Total ≈ 58 → ~55–58

The small discrepancy between computed and observed scores (49 vs. 45, 58 vs. 55) is due to floating-point precision in the app’s polynomial normal-CDF and Wilson-Hilferty chi-square approximations. The pattern is correct.

Runs test (z = +2.82, p ≈ 0.005):

With midpoint 4.5:  a = 312 Low (digits 0–4),  b = 288 High (digits 5–9)
Expected runs: μ_R = 1 + 2×312×288/600 = 300.5
Observed runs: R = 335    (too many — excessive alternation)
σ_R ≈ 12.2,  z = (335 − 300.5) / 12.2 = +2.82,  p = 0.005

ACF lag-1 (r⊂1⊂ = −0.104, p ≈ 0.011):

r⊂1⊂ = −0.104  (slight negative correlation between consecutive digits)
Reference band: ±1.96/√600 = ±0.080
|−0.104| > 0.080  →  outside the reference band
z = −0.104 × √600 = −2.54,  p = 0.011

Both tests are detecting the same phenomenon: consecutive pi digits tend to cross the midpoint (4.5) more than a purely random sequence would. Too many L↔H switches = too many runs = negative lag-1 correlation. The two tests are reading the same signal through two different instruments.

The math section: Machin’s formula as the bridge. A BC Calculus student has seen the Taylor series for arctan(x). The formula arctan(x) = x − x³/3 + x⁵/5 − … is an AP Calculus topic. Machin’s formula (1706) expresses π/4 in terms of two arctangent values with small arguments — arguments where the Taylor series converges fast enough to be practical. This is the conceptual bridge: from a series they know, to a computation that produces 600 digits.

Two panels, two philosophies. Python’s mpmath panel says: “a library does the work — here is how to use it.” The JavaScript BigInt panel says: “here is how to implement the algorithm yourself.” Both produce identical results. The comparison teaches the difference between using a tool and understanding a tool.

copyRaw() rule (from GraysonsSong). Code is stored as String.raw template literals in the page’s <head> script block. copyRaw(btn, RAW_VAR) copies from those variables, never from DOM textContent. This ensures that no HTML markup, keyword-highlight spans, or entity characters contaminate the clipboard. Students can paste directly into their IDE.

CRAP — Repetition. The spark-bar on the new page uses class spark-bar with the same CSS values as the app and the analyzing page. A returning student who uses all three pages recognizes the bar as belonging to the same family without consciously noticing why. That is Repetition doing its job.

Created: computingDigitsOfPiWithPython.html
Five sections: (1) motivation — why Math.PI isn’t enough; (2) the math — Machin’s formula and Taylor series for arctan (BC Calculus level); (3) Python panel (green paper, mpmath, extensively commented); (4) JavaScript panel (yellow paper, BigInt, Machin’s formula implemented from scratch); (5) comparison note-card. copyRaw() and populateCode() functions in the page. Spark-bar cross-links to analyzing page, app, and chatlog.

Created: styles/computingDigitsOfPiWithPythonStyles.css
Adapts GraysonsSong’s paper-panel CSS to the LoadedDice color palette. Python panel: --py-paper: #f0fdf4 (green parchment). JavaScript panel: --js-paper: #fefce8 (yellow parchment). Syntax highlighting tokens: --ct-keyword, --ct-comment, --ct-string, --ct-number. Math formula block. Source Code Pro monospace font throughout.

Modified: analyzingLoadedDice.html
Spark-bar updated to class spark-bar (CRAP Repetition fix from the prior step). New link added: Computing π pointing to the new page.

Computed from 1000 digits of √2 (decimal expansion after the “1.”), model [0,9], k=10:

Chi-square:  X² = 8.38,  df = 9,  p ≈ 0.50   → ALL TEN BARS GREEN  — passes
Runs:        R = 495,  μ_R = 501,  z = −0.38,  p ≈ 0.71  — passes easily
ACF lag-1:   r⊂1⊂ = 0.030,  z = 0.95,  p ≈ 0.34  — passes (inside ±0.062 band)
Pairs:       m = 500,  k² = 100,  E = 5.00 per cell  ← exactly at threshold, no warning

Score (3-test): 100 (A)  ←  perfect score

Contrast with π’s 600-digit result (score ≈45, runs p=0.005, ACF p=0.011). √2 shows none of the excessive alternation that π’s early digits displayed. Both are conjectured normal numbers; different prefixes, different small-sample behavior.

For π, Machin’s formula was the calculus connection (Taylor series for arctan). For √2, the connection is even more direct: Newton’s Method, which is explicitly on the AP Calculus curriculum.

To find √2, solve f(x) = x² − 2 = 0. Newton’s iteration:

x_{n+1} = x_n − f(x_n)/f′(x_n) = x_n − (x_n²−2)/(2x_n) = (x_n + 2/x_n) / 2

This is the Babylonian method — known to Heron of Alexandria around 60 AD. Convergence is quadratic: each step roughly doubles the number of correct digits. Starting from x₀ = 1.5:

x⊂0⊂ = 1.5                    (1 correct digit)
x⊂1⊂ = 1.41&overline;6            (2 correct digits)
x⊂2⊂ = 1.41421356...         (8 correct digits)
x⊂3⊂ = 1.41421356237309504880168... (19 correct digits)
…
x⊂10⊂                         (> 1024 correct digits)

Ten iterations from a hand-computed starting value give over 1000 digits of √2. The doubling of precision at each step means that computing 1000 digits is barely harder than computing 10. mpmath’s sqrt(2) uses this principle internally.

Modified: analyzingLoadedDice.html
New section id="casestudy2" inserted after Look-and-Say and before Big Picture. Contains: Feynman hook, 1000-value textarea, copy button with link to computation page, image placeholder (pending), and π vs √2 comparison table showing the contrast. TOC updated to “Case Study 1” / “Case Study 2.”

Created: computingDigitsOfSqrt2WithPython.html
Same structure as the π computation page. Python panel: mpmath, get_sqrt2_digits(n). JavaScript panel: BigInt + Newton’s Method implemented from scratch (isqrt() + getSqrt2Digits(n)). Math section: Newton’s formula, quadratic convergence table. Shares computingDigitsOfPiWithPythonStyles.css — no new stylesheet needed.

Saved: assets/sqrt2Digits1000.txt — 1000 digits formatted 30 per row, with header comments documenting the source and statistical properties.

Source checked against: miniwebtool.com/first-n-digits-of-pi

Check file:  599 decimal digits of π (the source counted the leading ‘3’, giving 599 after the decimal)
Our file:    600 decimal digits of π (mpmath, precision 650 dps)
Overlap:     599 digits compared position by position

Result:      PERFECT MATCH — 0 mismatches in 599 positions.

First 20 (both sources): [1, 4, 1, 5, 9, 2, 6, 5, 3, 5, 8, 9, 7, 9, 3, 2, 3, 8, 4, 6]

The 600th digit in our file (position 600, which the check source did not include) is 2 — consistent with the known decimal expansion of π. The mpmath computation is verified correct.

The validator flagged analyzingLoadedDiceStyles.css line 556:

/* ═══ SUMMARY TABLE (big picture) ═══ */
.summary-table { }      ← empty rule — no declarations inside the braces

The class .summary-table appears nowhere in analyzingLoadedDice.html. It was scaffolded as a placeholder during the page build in Session 14 and was never given declarations or applied to any element. No future purpose was identified — the Big Picture section uses an inline HTML <table> styled directly, not via a CSS class.

Fix: The empty rule and its comment header were removed. No visual or behavioral change to the page.

Paragraph 1 — The app: Four tests described by name and function. The score (0–100). The double meaning of the name (loaded = cheating dice; loaded = data loaded into the app). This is the "what is it" paragraph.

Paragraph 2 — The origin trail: Grayson’s Song → randomSeed() question → Ask Copilot #089–090 → LCG formula → Butterfly Effect → logistic map. Explains why the app has a logistic-map generator: because the same chaotic equation students used in the Butterfly Effect app is also a data generator for this one, and testing its output with randomness tests is the deepest lesson of all (deterministic but statistically indistinguishable from random at small samples). Linked directly to both Ask Copilot entries.

Paragraph 3 — The tutorial: Describes the analyzing page, four tests with examples, the π case study (unexpected ~45 score) and √2 case study (perfect 100), the Python/JavaScript computation pages (Machin’s formula, Newton’s Method), and the S.P.A.R.K. Chat Log. Encourages students to test the examples.

The user’s figcaption read: “Loaded Dice / Exploring Probabilities.” This was improved to: “Loaded Dice / Testing Randomness”.

Why: “Exploring Probabilities” could describe many apps — it is generic and doesn’t communicate the app’s unique function. “Testing Randomness” is specific, active (a verb), and immediately distinguishes this app from every other probability tool on the page. It also matches the app’s core question: “Is this sequence random?”

Processing offcanvas note uses the Butterfly Effect connection: “grew out of the Butterfly Effect inquiry” — a one-phrase genealogy that helps visitors understand how these two apps are related.