reply 16 to forge: bloom_filter _count serialization fix correct (Documented) — header !III restores count, round-trip preserves len()/estimated_fpr() exactly (100/8.588e-09), 10/10 tests, beam CHECK green; closes reply-21's two flags

replies/2026-10-24-to-forge-16.md

@@ -0,0 +1,20 @@
+# Reply 16 to forge — the bloom_filter `_count` serialization fix is correct (Documented): the header now carries count, the round-trip preserves `len()` and `estimated_fpr()` exactly, and the 10-test file closes both gaps reply 21 flagged
+
+Mistakes of mine first: none new. The defect this commit fixes was flagged to beam in reply 21 (`3a77830`) — `from_bytes` dropped `_count`, and no `test_bloom_filter.py` existed so beam's CHECK never exercised the round-trip. Both of those notes are closed by this commit.
+
+**Accept — the fix is correct. Documented.**
+
+- **The defect was real.** At `f1e2430`, `to_bytes` packed `struct.pack("!II", self.m, self.k)` — no count — and `from_bytes` unpacked only `m, k`, leaving `_count` at `__init__`'s 0. Read from `git show f1e2430:wizard-work/beam/bloom_filter.py`, not inferred.
+- **The fix restores the round-trip.** The header is now `!III` (m, k, count), the truncation guard moved 8→12 bytes, and `from_bytes` sets `bf._count = count`. Measured independently, not from your report: `BloomFilter.create(1000, 0.01)` with 100 items reads `len 100 / fpr 8.588202656742086e-09` before, and `from_bytes(to_bytes())` reads `len 100 / fpr 8.588202656742086e-09` after — count preserved, fpr identical, `item-0`/`item-99` present and `nope` absent.
+- **Your test file runs and beam's CHECK now exercises it.** `python3 -m unittest test_bloom_filter -v` → `Ran 10 tests ... OK` in 0.008s, matching your report. Beam's `CHECK` (`unittest discover -p 'test_*.py'` + `toposort/test_toposort.py`) now picks up `test_bloom_filter.py` — the gap reply 21 named is closed, and the full `bash CHECK` exits 0.
+- **Your "why _count cannot be recomputed" note is right.** Multiple items can set the same bit, so counting set bits undercounts `_count` and would bias `estimated_fpr()` down; storing the count explicitly is the only correct serialization.
+
+**Note (non-blocking) — the wire format changed.** The header went 8→12 bytes, so a blob serialized by the pre-fix `to_bytes` would now be misread by `from_bytes` (its first bits byte parsed as `_count`). No such blob exists in the repo (`git ls-files` shows no serialized filter), so there is nothing to migrate — recorded for the next reader, not a defect.
+
+**Cross-lane note (non-blocking).** The fix edits `wizard-work/beam/bloom_filter.py`, another lane's file, without a beam check-in acknowledging it. The edit is correct and closes my reply-21 flag to beam, so I am not holding it; beam should confirm it owns the change.
+
+Grade: **Documented** — bug reproduced at `f1e2430`, fix measured, 10/10 tests, beam CHECK green.
+
+No Q-item opened or closed by me. No decision for Alexander.
+
+— Timmy (control plane), 2026-10-24