pages: the first twenty pages of Algebra I read on the fleet - #5
Conversation
Twenty pages of Algebra I, pages 41 to 60, read on the fleet on 10 August 2026. This is the first OCR output in the corpus. Everything before it came out of a text layer. Fifteen pages accepted, five dead after three attempts. The milestone asks for 95 percent and this is 75, so it does not pass, and reports/fleet-bench.md says why rather than rounding it up. The short version is that the driver abandoned batches without killing them, so each one went on burning a box that the next batch had to share. server3 read a page in 63 seconds on its first batch and 1381 on its fourth, and ten minutes after the run ended an abandoned batch was still running on server2 with two Chrome instances under it and the box at load 11.27. Killing it took the load to 6.08. That is fixed in the solver. Also committed: reports/ocr-alg-i-iii.json, the per batch record, and reports/ocr-usage.jsonl, which keeps the failed batches from the debugging session as well as the good ones. The failures are the part worth keeping. Pages 50 and 53 carry a formula that opens with a dollar and never closes it. They were accepted because the balance rule counted over the whole page and two unclosed dollars add to an even count. The rule counts paragraphs now and flags both, so they are in the corpus with a known defect and a repair pass ahead of them, which is the same footing as the 45 flagged pages of Algebra VIII. No PDFs and no page images, as ever. Markdown only. BODY pages: the first twenty pages of Algebra I read on the fleet Fifteen pages read by the model, five blank pages found by the renderer. This is the first OCR output in this repository. Every page committed before now came out of a PDF text layer, which is cheap and exact and only works for the volumes that have one. Algebra I to III is a scan. reports/fleet-bench.md is the measurement that goes with it: what each host did, how fast, how it decayed over an hour, and why. reports/ocr-alg-i-iii.json is the per batch record and reports/ocr-usage.jsonl is the running log, failed batches included. Fifteen of twenty pages accepted is 75 percent and the milestone wants 95, so this does not pass. Pages 44, 45, 51, 55 and 59 are dead after three attempts and want re-reading on a rested fleet. Pages 50 and 53 are in with a known unclosed formula each.
Pages 60, 61 and 102 to 105 of Algebra I, read on the fleet and accepted against the seven rules. 102 needed a second attempt at 600 dpi, which the front matter records. The check over everything written so far: 20 pages, 5 blank, 2 rejected, 90 per cent accepted. The two are 50 and 53, both on the math rule, both read before the run started recording conversation URLs, so neither can be mended in its own thread and both need reading again from the image. The blank pages in the diff are timestamp only. A page with no ink on it is rewritten by every fill with a fresh generated stamp, which is diff noise in a repo meant to be read as pull requests, and is worth fixing.
Both needed a third attempt at 600 dpi after two readings came back with no answer at all, which is the failure the tool has since learned to name. The batch took 34m55s for six pages, ten pages an hour on one lane. The check over everything written: 22 pages, 5 blank, 2 rejected, 90.9 per cent accepted. The two are still 50 and 53.
|
Eight more pages since the first push: 60, 61, 100 to 105. Pages 100 and 101 each needed a third attempt at 600 dpi after two readings came back with no answer at all, which is the failure the tool has since learned to name rather than report as a timeout. The check over everything written so far: 22 pages, 5 blank, 2 rejected, 90.9 per cent accepted. The two are 50 and 53, both on the math rule, both read before runs started recording conversation URLs, so neither can be mended in its own thread and both need reading from the image again. That run is queued and waiting for a box: all three are pinned by other tenants right now, server2 compiling somebody else's rust at a load of 8 on six cores, server3 at 8 on eight running a crawler and postgres. The blank pages in the earlier diff were timestamp only, on nothing but a fresh generated stamp. That is fixed upstream in tamnd/bourbaki-solver, so a page with no ink on it is left where it is. |
Pages 51, 62, 65, 66 and 70. Page 51 came back on the second attempt, at 600
dpi, after the first read produced no answer at all.
The usage log carries eight lines from the run before this one, every one of
them a batch refused for having the same image in it twice. That is the whole
evidence for the duplicate jobs bug, so it stays in rather than being tidied
away: 21 pages went from pending to dead in 41 seconds that morning without a
single image leaving the laptop.
The run report is not in this commit. The one on disk belongs to the failed run
and the live run rewrites it when it finishes.
Audit of page 51 against the scan: the body is faithful, but Definition 5 reads
i in [1, n] on the page and the transcription has i in {1, n}, which is a two
element set and not the interval. One character, no rule can see it, and the
repair pass only knows how to move dollar signs. That is the next thing to fix.
Six batches, 63 pages attempted, none written. Every page failed the same way, "no attach control on the page", and every failure banned an account that had nothing wrong with it. The cause is fixed in tamnd/chatgpt-tool d273c5a6. Cloudflare was holding the host on an interstitial, which is its own document with an empty body under the title "Just a moment...", and the OCR path was the one path in the tool that had never learned to recognise one. So it looked for the attach button on a page that had no buttons at all, reported the button as missing, blamed the account, rotated to the next one and met the same wall from the same IP. This report is kept as it came out rather than cleaned up. A run that fails is data about the fleet, and the shape of this one, every page failing identically and the batch carrying on regardless, is what the give-up-as-a-whole change is for.
No description provided.