FA-72927 / Probabilistic sketches / Member archive

Counting Bloom filter with 4-bit counters: repeated probe position counted twice · case 02

An item whose stride wraps onto an earlier position inflates that counter, and later removals leave residue or drain other items.

Member previewVariant 2 · 3 implementations · 9 checks per implementation

Case contract

Input {m, k, ops}; items are pre-hashed non-negative integers. Positions are the distinct values of (h1 + i*h2) mod m for i in 0..k-1 with h1 = item mod m and h2 = 1 + (item div m) mod (m-1), in first-seen order. add increments each distinct position once, saturating at 15. A saturated counter is sticky: remove never decrements it. remove is atomic: if any position is zero the result is "absent" and nothing changes; otherwise it decrements every non-saturated position. has requires every position to be positive. Return [results, counters].

Why this case matters

Counting Bloom filters support deletion in caches and routing tables; counter overflow, duplicate positions and non-atomic removals create false negatives that are otherwise impossible.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
hot item with repeated positions	`[["added", "added", "added", "added", "added", "added", "added", "added", "removed", "removed", "removed", "removed", "removed", "removed", "removed", "removed", true], [0, 0, 0, 15, 0, 0, 0, 0, 0, 0, 15, 0, 0, 0]]`	`[["added", "added", "added", "added", "added", "added", "added", "added", "removed", "removed", "removed", "removed", "removed", "removed", "removed", "removed", false], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]]`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.