Apr 5, 2025

I was thinking today about the bloom filtering estimation I did previously. I wasn't entirely happy with the estimates that I was getting from Grok, so I finally decided to just make an equivalent bloom implementation that could serve as a drop-in replacement for sieve. I just completed that, with a full test quite, and am now running the scenario with the same size filters on the tables, and reporting false positive rates for the point table. This will give me a block-by-block comparison. Tuning is potentially a variable. I know that for Sieve LF=1.5, m=32 ... k=4 is optimal. Grok says that for Bloom LF=1.5, m=32 ... k=5 is optimal. The advantage of Bloom is that it doesn't store k values, so it can use all 32 bits for filtering (vs. 28 for Sieve in this example). I'll run Bloom at k=4 and k=6 just to make sure 5 is its optimum.