Re: [Bloom] Some questions

From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2025-05-19 18:44:37

El 18/05/2025 a las 23:38, Ivan Matek escribió:
> Had a bit more time to think :) so here are my replies and few more 
> questions.
>
>
>     >Â  Â  Â 5. Why is BOOST_ASSERT(fpr>=0.0&&fpr<=1.0); not
>     > BOOST_ASSERT(fpr>0.0&&fpr<=1.0);
>     >Â  Â  Â , i.e. is there benefit of allowing calls with impossible
>     fpr argument?
>     fpr==0.0 is a legitimate (if uninteresting) argument value for
>     capacity_for:
>
>     capacity_for(0, 0.0) --> 24
>     capacity_for(1, 0.0) --> 18446744073709549592
>
>     The formal reason why fpr==0.0 is supported is because of symmetry:
>     some calls to fpr_for actually return 0.0 (for instance,
>     fpr_for(0, 100)).
>
>
> This is a bit philosophical, but I actually do not feel this is correct.
> First of all  is (0, 0.0) only usecase where fpr of 0.0 makes sense? 
> i.e any time when n>0 fpr 0.0 is impossible(or I misunderstood 
> something).

Yes, it is impossible: the capacity would have to be infinite --the maximum
attainable value is returned instead, though this is of little value as
OOM would ensue (as you point out below).

> So assert could be implies(it is funny because we had discussion about 
> implies on ML few months ago), so something like:
> BOOST_IMPLICATION(fpr == 0.0, n == 0);
>
> Similarly for (1, 0.0) I do not believe result should be size_t max 
> value, as this is not correct value. Now we both know you will OOM 
> before noticing this in reality,
> but even if we imagine magical computer that can allocate that much 
> memory fpr is not 0.0.

I understand your point and can relate to it, but consider this:

capacity_for(1, 1.E-200)

Is this legit? OOM will happen here, too. Where do we put the
limit?

> If this library was not C++11 I would suggest std::optional as return 
> type, but as it is boost::optional seems like best option.
> Now I know people might think I am making API ugly for users, but I 
> really do not think a bit more typing is such a big problem when
> the alternative is people messing up(probably not when using constants 
> in code, more likely when they dynamically compute something). Bloom 
> filters are important, but they are not like json or protobuf where 
> they are everywhere in codebase, users needing to use a bit uglier
> API in 10LOC in 1M LOC codebase does not seem like a big deal to me.
>
> So in examples above:
> capacity_for(0, 0.0) - > min_possible_capacity
> capacity_for(1, 0.0) - > nullopt
>
>
> Few more questions I thought of recently, apologies in advance if I 
> misunderstood something.
> [...]

I will address these comments tomorrow (out of time today),
but I felt like answering to the first prt of your post now.

Joaquin M Lopez Munoz