(c) Nov 8 2026 by Philip John Jatzek & STORM (lead programmer/team member) ChatGPT all rights reserved

JATZEK PERIODICAL 2

Million Character Search
and Precision Results

Experiments on Pi

Philip John Jatzek and STORM ChatGPT
Research record dated November 8 2026

The completed result

Our search completed all 85,992 candidate BASE values at a buffer length of one million printed characters. The best coverage result was BASE 28.406505541, with 990,931 covered positions, 9,069 GAP positions and 99.0931% coverage under our climb/fall count-balance rules. The separate MATCH and combined-score winner was BASE 19.264. [1]

The final verification record passed. Subsequent checks reproduced the coverage winner at higher calculation precision. Eight nearby BASE tests through 12 decimal places and 32 selected tests through 28 decimal places produced no coverage improvement. These refinements confirm the recorded winner within the tested set; they do not establish a best value over every possible real BASE. [2, 3]

Measure	Coverage winner
BASE	28.406505541
BRDV	1,000,000 printed characters
Coverage	99.0931%
Covered positions	990,931
MATCH	3,628
GAP positions	9,069
GAP blocks	4
MATCH blocks	4

This periodical explains how the stream is generated, how the scores are counted, how the million-character search was completed and verified, and what the precision tests add to the result. The complete refinement tables and reproduction instructions appear later in the document.

Philip John Jatzek is the project contributor and overseer. STORM ChatGPT is the programming and analysis collaborator. The original archive retains the project credit record.

1 What the experiment measures

BASE and the generated stream

BASE is the multiplication parameter in a repeated transformation of the fractional part of pi. The starting remainder is pi minus 3. At each iteration we multiply the remainder by BASE, emit the integer part of the product, and keep the fractional remainder for the next iteration. The original pi seed stays the same while the BASE parameter changes.

For BASE 28.406505541 the parameter is the exact rational number 28406505541 divided by 1000000000. A 28-place decimal input is likewise parsed as an exact integer numerator over a power-of-ten denominator. The stored input digits define the parameter; they are not a rounded estimate of a hidden BASE.

The emitted integers are printed in ordinary decimal notation and concatenated without separators. For example, emitted values 1, 12 and 4 contribute the characters 1124. A two-digit emitted value therefore contributes two printed characters. Pattern windows can cross the boundary between two emitted values. This convention is essential when reproducing the scores.

BRDV and the two checkpoint schedules

BRDV is the retained length of that printed character buffer. In this issue BRDV 1,000,000 means one million characters, not one million recurrence iterations and not one million ordinary decimal digits of pi. The winning stream needed 609,578 emitted integer values to reach that length. [3]

We store sampled score rows from BRDV 30,000 through 1,000,000 in increments of 1,000, giving 971 rows per candidate. Separately, the MATCH accumulator is updated every 500 printed characters. The 1,000-character reporting interval and the 500-character MATCH interval serve different purposes.

The fifteen climb and fall pairs

The implemented detector uses every increasing four-character combination drawn from 0, 1, 2, 3, 4 and 5, paired with its reverse. An increase need not use consecutive digits: 0124 is a valid climb. Overlapping windows count. Characters 6 through 9 may occur in the stream, but they are not members of these pattern pairs.

Pair	Climb	Fall
1	0123	3210
2	0124	4210
3	0125	5210
4	0134	4310
5	0135	5310
6	0145	5410
7	0234	4320
8	0235	5320
9	0245	5420
10	0345	5430
11	1234	4321
12	1235	5321
13	1245	5421
14	1345	5431
15	2345	5432

2 How the scores are counted

A balanced pair and a covered position

Each pair has two cumulative counters: the number of climb occurrences and the number of fall occurrences encountered so far. A pair is active when the two counters are equal and both are greater than zero. Zero climbs and zero falls do not qualify.

A position is covered whenever at least one of the fifteen pairs is active. Coverage counts the union of those positions, so a character is counted once even if several pairs are active. A balance can remain active across a long stretch of the stream until another occurrence changes one of its counters. Covered positions are therefore not limited to the four characters inside a detected pattern.

As a simple example, a pair with three climbs and three falls is active. A fourth climb changes its counts to four and three, making that pair inactive. A later fourth fall restores equality. Another pair may remain active during the intervening positions, so overall coverage can continue even while the first pair is inactive.

MATCH and blocks

At each 500-character boundary we add the number of currently active pairs to MATCH. One boundary can contribute between zero and fifteen. MATCH is the sum of those contributions, not the number of pattern occurrences, the number of equal digit pairs, or the count of covered characters. At one million characters there are 2,000 such boundaries.

A MATCH block is a contiguous run of covered positions. A GAP block is a contiguous run of uncovered positions. The initial uncovered prefix is included. GAP positions are the buffer length minus covered positions. Coverage percentage is the covered-position count divided by the buffer length, multiplied by 100.

The four ranking categories

Category	Primary ranking
Coverage	Most covered positions
MATCH	Largest MATCH total
Combined	Largest covered-position count times MATCH
Fewest GAP blocks	Smallest number of GAP blocks

At a fixed BRDV, multiplying coverage fraction by MATCH produces the same ordering as multiplying covered-position count by MATCH. The archived implementation resolves coverage ties with MATCH, then GAP blocks, total blocks and numerical BASE. MATCH ties use coverage before the remaining tie-breakers. Combined ties use coverage and MATCH before the remaining tie-breakers. [1]

The fewest-GAP category must be read together with coverage. A stream that is entirely uncovered has one GAP block and can beat useful streams on that narrow criterion. This issue reports that raw category faithfully but does not treat it as the preferred scientific result.

3 From the earlier buffer to the million character search

Earlier 500,000-character tests had made the 28 range promising. BASE 28.406505 covered 498,867 positions, or 99.7734%, with 1,133 GAP positions. Its refinement 28.406505887 had 1,279 GAP positions but only one GAP block. Those are different strengths, and neither score by itself establishes what happens when the buffer doubles. The original million-search candidate records preserve these earlier endpoints and hashes. [1]

BASE	Coverage at 500000	Coverage at 1000000	GAP at 1000000
28.406505	99.7734%	73.3711%	266,289
28.406505887	99.7442%	71.6525%	283,475
28.406505541	98.1862%	99.0931%	9,069
19.264	95.3570%	95.4370%	45,630

The longer run changed the ranking. BASE 28.406505541 had lower coverage than 28.406505 at 500,000 characters, yet it became the million-character coverage winner. Its GAP count stayed at 9,069 from 500,000 to one million. For the earlier leader, the additional half-million characters introduced substantial uncovered regions. Comparing percentages therefore requires the same BASE, buffer length and scoring rules.

The candidate set and stored results

The search included the 78,000 original grid points from 3.000 through 80.999 at steps of 0.001, together with previously tested fractional refinements. Numerical deduplication produced 85,992 candidates: 78,000 grid values and 7,992 additional refinements. The 28 range and selected earlier winners were prioritized, but all candidates had to complete before a final ranking could be announced.

Each candidate produced 971 sampled score rows, for 83,498,232 rows across the completed search. Each row contains BRDV, covered positions, MATCH, GAP blocks and MATCH blocks. The runner stored compressed score records in SQLite with SHA-256 checksums. For every candidate, the first 471 sampled rows, ending at BRDV 500,000, had to reproduce the saved earlier-prefix hash.

Completion and recovery

The archived progress record marks all 85,992 candidates complete at November 7, 2026, 19:21:20 UTC. The runner used coherent database snapshots, a watchdog and periodic durable saves so completed candidates could be reused after interruption. These mechanisms supported recovery; the evidence of completion is the finished candidate count, complete database and final verification record, rather than a heartbeat or an estimate of elapsed time.

The final archive retains a stale verification-pending label in progress.json. The later verification.json explicitly records complete true and verification passed, and Results.md records the verified winners. When inspecting this record, the later verification result takes precedence over that older progress label. [1]

4 The final million character results

Category	BASE	Coverage	MATCH	GAP positions	GAP blocks	MATCH blocks
Coverage	28.406505541	99.0931%	3,628	9,069	4	4
MATCH	19.264	95.4370%	4,806	45,630	12	12
Combined	19.264	95.4370%	4,806	45,630	12	12
Fewest GAP blocks	3	0.0000%	0	1,000,000	1	0

BASE 28.406505541 is the best choice when the objective is covered positions. BASE 19.264 is the best choice among the tested original candidates when the objective is MATCH or the combined score. The experiment has separate winners because the objectives reward different features of the same stream.

The raw fewest-GAP winner, BASE 3, is a degenerate case. Its recurrence emits only 0, 1 and 2, so it cannot contain any of the four-distinct-digit climb patterns. Coverage and MATCH remain zero, leaving the whole buffer as one GAP. That result explains why GAP-block minimization needs an additional coverage condition before it can serve as a useful optimization target.

Where the coverage winner still has gaps

We reconstructed the coverage intervals from the saved winning stream using the independent event-based scorer. The following coordinates are one-based and inclusive. Their lengths add to 9,069 characters.

GAP block	Start	End	Length
1	1	3,240	3,240
2	3,777	6,937	3,161
3	9,943	11,753	1,811
4	13,244	14,100	857

The covered intervals are 3,241–3,776; 6,938–9,942; 11,754–13,243; and 14,101–1,000,000. Every position after 14,100 is covered under the active-pair rule. This long final interval explains the high overall coverage and the unchanged GAP count in the second half of the buffer. It does not establish that coverage continues beyond the tested endpoint.

The independently rescored endpoint contains 1,429 climb occurrences and 1,429 fall occurrences in total across the fifteen pairs. Equal totals alone are not the coverage rule: coverage depends on each pair’s cumulative equality along the stream. Of the 2,000 MATCH boundaries, 1,982 are covered, while the sum of active pairs at those boundaries is MATCH 3,628. [3]

Coverage and combined score compared

BASE	Covered positions	Coverage fraction times MATCH	Covered positions times MATCH
28.406505541	990,931	3,595.097668	3,595,097,668
19.264	954,370	4,586.702220	4,586,702,220

The MATCH winner has fewer covered positions but a larger combined product. The fraction-based and count-based combined scores differ only by the common buffer length of one million, so they identify the same winner.

Selected buffer checkpoints for the coverage winner

BRDV	Coverage	Covered positions	MATCH	GAP positions	GAP blocks	MATCH blocks
30,000	69.77000%	20,931	77	9,069	4	4
80,000	88.66375%	70,931	355	9,069	4	4
100,000	90.93100%	90,931	466	9,069	4	4
250,000	96.37240%	240,931	1,117	9,069	4	4
500,000	98.18620%	490,931	2,030	9,069	4	4
750,000	98.79080%	740,931	2,884	9,069	4	4
1,000,000	99.09310%	990,931	3,628	9,069	4	4

Selected buffer checkpoints for the MATCH winner

BRDV	Coverage	Covered positions	MATCH	GAP positions	GAP blocks	MATCH blocks
30,000	89.80000%	26,940	105	3,060	3	3
80,000	95.23750%	76,190	309	3,810	5	5
100,000	96.19000%	96,190	424	3,810	5	5
250,000	98.47600%	246,190	1,259	3,810	5	5
500,000	95.35700%	476,785	2,258	23,215	9	8
750,000	93.91600%	704,370	3,276	45,630	12	12
1,000,000	95.43700%	954,370	4,806	45,630	12	12

These are seven representative checkpoints from each winner’s complete 971-row record. The original candidate ranking was evaluated at the one-million-character endpoint. An advantage at an earlier checkpoint does not imply an endpoint win. [1]

5 Verification of the completed search

Verification was performed at several levels. Keeping those levels separate shows what was tested and avoids implying that every candidate received the same expensive independent regeneration.

Stored record validation

The final verifier checked SQLite integrity, the expected count of 85,992 candidate records, each decompressed record’s SHA-256 hash, the preserved 500,000-character prefix-score hash, the exact 971-row checkpoint schedule and basic score bounds. It recomputed the four endpoint rankings from the stored records. The archived verification report records these checks as passed. [1]

Independent regeneration of endpoint winners

There were three distinct original endpoint winners: 28.406505541, 19.264 and 3. Each was regenerated with both the optimized generator and the separate reference generator using 512 guard bits. The resulting million-character streams were compared character for character. The event-based Python scorer then checked every one of the 971 stored checkpoints for each distinct winner.

This independent scoring path finds pattern events, constructs the intervals during which each pair is balanced, merges their union and derives coverage and block counts. Its method differs from the optimized generator’s rolling-window update. Exact stream comparison tests generation; independent rescoring tests interpretation of the stream. Both are needed for a reproducible result.

Checks during preparation of this issue

The original ZIP passed its internal CRC check, and every listed file hash in its snapshot manifest matched. The two later precision packages also passed ZIP integrity checks. Their full winner reproductions, score rows and saved JSON results provide the evidence used in this issue. Integrity checks establish that the saved bytes are consistent; they complement the numerical and scoring checks rather than replacing them.

The coverage-winning million-character stream has SHA-256 digest e06a80812be972e8a6802fa5e9498725de522cdf264b4e70c74b91566e7bae09. A later run can compare this fingerprint directly with the saved stream, without depending on a displayed percentage.

6 Calculation precision and BASE precision

Two different meanings of precision matter here. Calculation precision controls the numerical uncertainty while generating a stream for one fixed BASE. BASE precision controls how finely we choose the parameter itself. Increasing calculation precision should reproduce an already certified result; changing a BASE digit generally defines a different experiment.

Precision change	What changes	Expected role
512 to 1024 guard bits	Arithmetic safety margin	Check numerical stability
9 to 12 decimal places	Allowed BASE input detail	Test finer parameter choices
12 to 28 decimal places	Exact parameter representation	Test still closer rational inputs

The generator uses a finite-precision approximation to pi with extra guard bits and an interval that tracks uncertainty. For a BASE near 28.4 and a million-iteration budget, the working state requires millions of binary digits; “512 guard bits” means additional safety beyond that state budget, not a total precision of only 512 bits. Outward bounds must agree on an emitted integer before the optimized path accepts it.

The fixed BASE 28.406505541 was regenerated with 1,024 guard bits. All one million printed characters and all 971 sampled scores matched the saved proof. The endpoint was independently rescored. That result confirms numerical stability for this tested stream; it does not identify extra BASE digits that improve coverage. [2]

The first eight nearby values

We tested the center plus and minus one unit at each of the ninth, tenth, eleventh and twelfth decimal places. The eight million-character tests used 512 guard bits. None exceeded the center’s 99.0931% coverage. The best neighbor in this first refinement was 28.406505540 at 87.3206%. The full results appear in Appendix A. [2]

7 Extending the BASE input to 28 decimal places

The earlier optimized implementation stored the BASE numerator and denominator in machine integers. That representation was not suitable for arbitrary 28-place decimal inputs. We changed the parameter representation to GMP arbitrary-precision integers and used exact integer multiplication for the recurrence updates and precomputed BASE powers. This preserves every supplied decimal place instead of silently truncating the suffix.

The decimal BASE is still used to form conservative floating bounds for the existing fast digit predictor. The accepted block advances the underlying state with the exact rational numerator and denominator. The implementation therefore preserves exact parameter input while retaining bounded numerical approximation of the pi-seeded state.

Validation before the new search

Four implementation cases passed independent 10,000-character comparisons with a Python exact-rational interval reference initialized from higher-precision mpmath pi. The cases included the center padded with zeros, the nearest lower and upper 28-place values, and a nontrivial suffix ending in 1234567891234567891. Each of the 32 search candidates subsequently passed the same independent prefix comparison.

The extended implementation also regenerated the complete million-character center using 1,024 guard bits. Its stream matched the previous winner exactly, its 971 score rows matched the saved proof, and an independent Python rescore checked all 971 checkpoints. The existing winning result therefore survived the implementation change. [3]

The 32 candidate plan

For each decimal position from 13 through 28, we tested the center plus and minus one unit at that position. This produces 32 selected neighbors. All inputs were written with 28 digits after the decimal point and computed as exact rationals. Each million-character test used 512 guard bits and retained the same 971 score checkpoints.

The test set samples sixteen distances on both sides of the center. It does not enumerate all intervening suffixes, combine arbitrary suffix patterns, or follow a guarantee that coverage improves smoothly as BASE changes. The complete exact input strings and endpoint results are in Appendix B.

The refinement result

None of the 32 neighbors improved the center. The best new neighbor was 28.4065055409999990000000000000, with 98.0090% coverage, MATCH 3,477, 19,910 GAP positions and fifteen GAP blocks. The center remained at 99.0931%, MATCH 3,628, 9,069 GAP positions and four GAP blocks. [3]

The two nearest 28-place neighbors, 28.4065055409999999999999999999 and 28.4065055410000000000000000001, reached 50.9992% and 55.1137% coverage respectively. Their independently checked prefixes and different full-run scores demonstrate sensitivity to very small parameter changes. They do not indicate a numerical rounding failure.

Writing the center as 28.4065055410000000000000000000 gives the same exact rational parameter as 28.406505541. The added zeros record a format; they are not newly discovered nonzero winning digits. The valid conclusion is that exact 28-place testing is now supported and that these 32 trials did not improve the recorded winner.

8 What the end result establishes

We have a completed finite search, preserved score records and a reproducible million-character coverage winner. The original search covered a stated grid and prior refinements. Later calculation-precision checks and parameter refinements strengthened confidence in the stored result without changing its winning BASE.

The 99.0931% figure belongs specifically to the union of positions where at least one nonzero cumulative climb/fall pair is balanced. It does not mean that 99.0931% of ordinary pi digits were predicted, that every pair is balanced, or that all positions contain a climb or fall pattern. The long final covered interval is a consequence of the defined stateful score.

This issue does not establish a global optimal BASE, a result for an infinite stream, a probability of chance occurrence, or statistical significance against a randomized null. The tested candidates were selected and ranked on the measured buffer. A future statistical claim would require a specified control and correction for that search process. A longer-buffer study would require an explicit new endpoint and verification plan.

Suggested next research steps

A useful follow-on experiment would freeze the current scoring rules and candidate-selection rule before extending the buffer. We could then compare 28.406505541 and 19.264 on the same longer endpoint, preserving the existing million-character prefix. A separate refinement could test a predeclared wider set of 28-place suffixes. Both would be new experiments with their own scope; neither is claimed as complete here.

Appendix A Nearby tests through 12 decimal places

Center BASE 28.406505541: coverage 99.0931%, MATCH 3,628, GAP positions 9,069 and GAP blocks 4. Each row below is a full million-character neighbor test. All values and scores come from the first precision package. [2]

BASE	Coverage	MATCH	GAP positions	GAP blocks	MATCH blocks
28.406505540	87.3206%	2,722	126,794	19	19
28.4065055409	72.2887%	2,249	277,113	49	48
28.40650554099	30.6983%	1,037	693,017	33	33
28.406505540999	47.2751%	1,451	527,249	61	61
28.406505541001	62.1687%	1,864	378,313	48	47
28.40650554101	81.6266%	3,045	183,734	23	23
28.4065055411	82.3302%	2,500	176,698	33	33
28.406505542	52.4317%	1,588	475,683	75	74

Reading the comparison

Each tested neighbor differs from the center by a fixed decimal increment. The results do not trace a smooth improvement curve. In particular, adding a nonzero digit after the ninth decimal place changes the exact BASE and generally regenerates a different stream, even though the beginning can remain similar for a short interval.

The full center reproduction in this package used a larger numerical safety margin and agreed exactly with the previously saved winner. That agreement addresses arithmetic precision for the center, while the eight rows above address parameter selection. These are separate findings.

Appendix B All 32 tests through 28 decimal places

Each BASE below has 28 digits after the decimal point. The center is 28.4065055410000000000000000000. Every row is a full million-character result; all 32 inputs also passed independent 10,000-character prefix checks. Headers repeat when the table continues onto another page. [3]

Exact BASE	Coverage	MATCH	GAP positions	GAP blocks	MATCH blocks
28.4065055409999000000000000000	51.0589%	1,337	489,411	37	37
28.4065055409999900000000000000	40.2894%	1,211	597,106	35	34
28.4065055409999990000000000000	98.0090%	3,477	19,910	15	15
28.4065055409999999000000000000	77.0978%	3,090	229,022	22	21
28.4065055409999999900000000000	44.4008%	1,300	555,992	61	61
28.4065055409999999990000000000	44.7837%	1,472	552,163	42	42
28.4065055409999999999000000000	56.0819%	1,693	439,181	37	36
28.4065055409999999999900000000	62.4189%	2,086	375,811	45	44
28.4065055409999999999990000000	58.0889%	1,790	419,111	64	64
28.4065055409999999999999000000	53.6288%	1,473	463,712	60	60
28.4065055409999999999999900000	52.5195%	1,475	474,805	54	53
28.4065055409999999999999990000	69.5988%	2,161	304,012	34	34
28.4065055409999999999999999000	67.7363%	1,998	322,637	45	44
28.4065055409999999999999999900	43.6072%	1,285	563,928	77	76
28.4065055409999999999999999990	40.6468%	1,561	593,532	41	40
28.4065055409999999999999999999	50.9992%	1,628	490,008	58	58
28.4065055410000000000000000001	55.1137%	1,814	448,863	59	59
28.4065055410000000000000000010	46.1084%	1,283	538,916	55	54
28.4065055410000000000000000100	79.5411%	2,790	204,589	26	25
28.4065055410000000000000001000	48.2824%	1,314	517,176	59	58
28.4065055410000000000000010000	64.2842%	1,992	357,158	49	48
28.4065055410000000000000100000	67.2497%	2,302	327,503	52	51
28.4065055410000000000001000000	61.4100%	2,093	385,900	42	42
28.4065055410000000000010000000	74.7139%	2,390	252,861	66	65
28.4065055410000000000100000000	76.4104%	2,513	235,896	47	47
28.4065055410000000001000000000	55.5946%	1,503	444,054	73	72
28.4065055410000000010000000000	68.6967%	2,214	313,033	23	22
28.4065055410000000100000000000	88.6154%	2,995	113,846	28	27
28.4065055410000001000000000000	68.0536%	2,419	319,464	35	34
28.4065055410000010000000000000	83.4448%	2,771	165,552	50	50
28.4065055410000100000000000000	67.2105%	2,081	327,895	50	49
28.4065055410001000000000000000	74.2895%	2,399	257,105	36	36

The best of these neighbors has 98.0090% coverage. The center has 99.0931% and remains preferred for coverage within the tested set. The JSON data retain exact BASE strings, certification messages, elapsed times and hashes of all 971 score rows per test.

Appendix C Reproduction and evidence record

The three saved packages

[1] STORM_Million_BRDV_Search.zip, saved version 440. Principal records are README.md, candidates.json, scores.sqlite3, progress.json, verification.json, Results.md, SNAPSHOT_MANIFEST.json and verified_winners. The source includes the optimized generator, separate reference generator, runner and final verifier.

[2] STORM_Precision_Check_2026-11-08.zip. Principal records are Precision_Report.md, precision_verification.json, neighbor_results.json, extended_decimal_validation.json, the regenerated baseline stream, raw checkpoint scores and source files for the eight-neighbor refinement.

[3] STORM_Precision_28_Decimals_2026-11-08.zip. Principal records are Precision_28_Report.md, generate_exact28.c, validate_exact28.py, refine28.py, candidate_plan.json, baseline_validation.json, implementation_validation.json, all_neighbor_prefix_validation.json, neighbor_results.json, summary.json, raw score rows, the center stream and MANIFEST.json.

Reproducing the 28 place refinement

Use a 64-bit Linux environment with Python 3 and mpmath, GCC, MPFR and GMP. Extract the third package into its own directory. The following commands build the exact-input generator, repeat the independent implementation-prefix tests and run or resume the 32-neighbor plan. The compiler command is shown on two lines using the shell continuation character.

gcc -O3 -ffp-contract=off generate_exact28.c -o generate_exact28 \
-Wl,-l:libmpfr.so.6 -Wl,-l:libgmp.so.10 -lm

python3 validate_exact28.py
python3 -u refine28.py

The runner reuses completed neighbor entries from neighbor_results.json and skips the baseline if baseline_validation.json already exists. A completely fresh rerun therefore requires a separate working copy with those generated records removed. Preserve the archived originals and their manifests. Do not treat a resumed run that performs no new work as a newly independent computation.

Raw score files contain repeated little-endian records of five unsigned 32-bit fields, in this order: BRDV, covered positions, MATCH, GAP blocks and MATCH blocks. There are 971 rows per million-character candidate. SHA-256 fingerprints of the raw bytes are recorded in the JSON results.