Bloom Filters: More than a space-efficient hashmap

Re:Bloom Filters: More than a space-efficient hashmap by gigatexal on Wednesday August 11, 2021 @05:22AM (#28139833)

Thanks for this context!

I wonder how the peer review process missed the use of an inefficent bloom filter implementation?

[ Parent | on HN ]

Re:Bloom Filters: More than a space-efficient hashmap by thomasmg on Wednesday August 11, 2021 @06:06AM (#28140151)

That's a good question! This paper also mentions "Dele. BF [43]" - the "The Deletable Bloom Filter: A New Member of the Bloom Family" https://www.researchgate.net/publication/260668624_The_Delet... . As far as I see, lookup is identical to the regular Bloom filter. Yet the vacuum filter paper lists the throughput of the Deletable Bloom Filter to be almost twice as the Bloom filter (1.95x). How can that be? Maybe I misunderstand something here.

Yes, a peer review is supposed to catch completely incorrect numbers. But in many cases, a reviewer doesn't have access to the source code, and no way to re-run the tests.

There's the "Replicated Computational Results initiative": https://jea.acm.org/rcr_initiative.cfm . Papers that pass this test will get a stamp certifying that its results are reproducible. The xor filter paper (where I'm a co-author) took part in this initiative.

[ Parent | on HN ]

Re:Bloom Filters: More than a space-efficient hashmap by gigatexal on Wednesday August 11, 2021 @05:25AM (#28139855)

ugh -- reading related papers on filters like the above exposed another pre-req i am missing: an understanding of math high enough to understand the math in the articles :/

[ Parent | on HN ]