docs: clarify BloomFilter contract after invert - #202
Conversation
- qualify the module- and type-level no-false-negative and false-positive guarantees as applying before invert() only - state in invert()'s documentation that after inversion both guarantees lapse and is_empty/bits_used/load_factor report raw bit state - document is_empty() in terms of bit state rather than insertion history - remove the unreachable BloomFilterBuilder::build panic documentation; both public constructors always produce a configured builder
Signed-off-by: tison <wander4096@gmail.com>
|
cc @leerho I wonder if a BloomFilter gets |
|
Thanks for your contribution @Renkai! |
|
@tisonkun, Much of the work on our end was done by Jan Malkin, who is at Apple now and is not allowed to contribute to Open Source :( ! If you write to him, thank him for work he contributed to us, and ask if you could have a few minutes to discuss this problem with him. Or describe it in the letter if it is not too complex. |
This closes #194
Summary
Documentation-only clarification of the BloomFilter contract around
invert(), addressing #194:invert()only (mod.rs#L31-L33)invert()'s documentation that after inversion neither the no-false-negative nor the false-positive guarantee holds, and thatis_empty()/bits_used()/load_factor()then describe the raw bit state rather than insertion history (sketch.rs#L241-L245)is_empty()in terms of bit state (num_bits_set == 0), which is what the implementation actually observes (sketch.rs#L265-L268)BloomFilterBuilder::buildpanic documentation: the builder has no public default constructor, and both public entry points always produce a valid configuration (builder.rs#L157)Design questions from #194
This PR makes the current semantics honest without committing to the open API decisions:
union()/intersect()). Whether to move it to a raw/diagnostic API remains open in Clarify BloomFilter semantics after invert and correct builder documentation #194; the documentation added here is accurate under either outcome.Validation