Re: [boost] Boost.Bloom_filter now in Sandbox (WAS Re: Interest in a Bloom Filter?)

Subject: Re: [boost] Boost.Bloom_filter now in Sandbox (WAS Re: Interest in a Bloom Filter?)
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2009-06-09 08:10:22

Dean Michael Berris wrote:
>>> 3. Have you considered the possibility to let
>>> the user specify M and K at constuction time rather
>>> than compile tiem and the pros and cons of both
>>> approaches?
>>>       
>> Yes, I have but I've put a premium at type safety and putting M and K
>> as part of the type instead of being a runtime value. The reasons are:
>>
>> 1. Specifying a static M allows the use of the standard bitset instead
>> of Boost's dynamic_bitset.
>> 2. A static K allows for enforcing the number of hash functions at
>> compile time instead of at runtime.
>> 3. Since M and K are not variable and are part of the type, it makes
>> little sense for me to have either of them set at construction time.
>>
>> One thing I might be amenable to is a static K and a runtime M, but
>> that makes the hash functions unable to determine statically the
>> bounds of the bitset (M). I can change the concept for the hash
>> function, but the simplicity of size_t(Input) just makes it easier for
>> users I think.
>>
>>     
>
> I thought about it a little more and I don't think I like the idea of
> a separate static and dynamic bloom_filter. If there are more reasons
> to allow for dynamically growing bloom filters, then I might support
> this.
>   
Dynamically growing bloom filters are technically impossible. The
request was for a bloom filter whose size is set at construction time.
This is useful e.g. because it allows the user of some filtering tool to
trade memory for reliability via a configuration file instead of having
to recompile.

Sebastian