The opposite of a bloom filter

I would argue that the opposite of a bloom filter doesn&#x27;t really exist, at least not in a satisfying way. A bloom filter&#x27;s size is dependent only on the desired false positive rate, whereas its opposite must be dependent on the size of the data. (And don&#x27;t be fooled by data that can be represented by a primary key, that&#x27;s not as general as a bloom filter.) I tried, with limited success, to explain my point of view in this answer on StackExchange: <a href="https:&#x2F;&#x2F;cstheory.stackexchange.com&#x2F;questions&#x2F;6596&#x2F;a-probabilistic-set-with-no-false-positives&#x2F;14455#14455" rel="nofollow">https:&#x2F;&#x2F;cstheory.stackexchange.com&#x2F;questions&#x2F;6596&#x2F;a-probabil...</a>

TLDR: a cache with LRU eviction, but only storing the keys, not the values.

&quot;A Bloom filter is a data structure that may report it contains an item that it does not (a false positive), but is guaranteed to report correctly if it contains the item (“no false negatives”).&quot;<p>I&#x27;m afraid that is not how it works. A Bloom filter can tell whether an item may be in the set (false positive) but can definitely tell an item is NOT in the set (no false negative).

&quot;It&#x27;s a cache.&quot; The use case is deduplication in an event-stream environment. This calls for exact matching without hash collisions.

Low memory version:<p>`return false;`