Just another Perl shrine | |
PerlMonks |
Re: Bloom::Filter Usage [patch]by thpfft (Chaplain) |
on Apr 20, 2004 at 19:11 UTC ( [id://346758]=note: print w/replies, xml ) | Need Help?? |
On closer inspection, Bloom::Filter is a bit broken, unless I'm badly misreading it: * The add() method doesn't actually add anything, because the new() method doesn't initialise the $self->{contents} hashref. it needs to be changed so that either the add method assigns directly to $self->{contents}, or the new() method changes 'keys' to 'contents'. that's probably just a typo. * because $self->{contents} is not populated, _calculate_filter_length() always returns undef, so the default filter length is always used. * because $self->{contents} is not populated, build_filter doesn't build a filter anyway. * the use of == to compare bitstrings in check() is generating warnings, as you've seen. Its purpose is to test that ($a & $b) is the same as $a, ie that all the on bits in $a are also on in $b, and never mind the off bits. Someone better than me at pack(), ie anyone at all, will know how to test equivalence using the bitstrings themselves: meanwhile, you can make it work by testing with the unpacked versions. * And anyway, it's not incremental. Every time you add a new key, the whole filter is rebuilt by way of a loop on $self->{contents}. This makes it more or less useless for your purposes: you presumably want an iterative check($_) || add($_) mechanism that can be placed in the equivalent of a while(<HUGE_FILE>) loop. As it stands, Bloom::Filter will perform another loop across your whole dataset-so-far for each input line, which might slow things down a bit. You will need to roll your own, I think, unless the author can be persuaded to accommodate both approaches as well as fixing the bugs, but if you patch Bloom::Filter with this, at least your test script should work:
In Section
Seekers of Perl Wisdom
|
|