This is where things get very strange for me

Here's the code I'm running as a test:

#!/usr/bin/perl

use strict;

use Digest::SHA1 qw(sha1);
use Bloom::Filter;

my $filter = Bloom::Filter->new(error_rate => 0.0001, capacity => 100)
+;

my @salts;

# None of these work
#  Option 1:
#   push @salts, "msis";
#  Option 2:
#   for my $salt (0..3) {
#       push @salts, sub { sha1($salt,$_[0]) };
#   }
#  Option 3:
#   for my $salt (0..3) {
#       push @salts, sha1($salt,$_[0]);
#   }

$filter->set_salts(@salts);

$filter->add("Foo");
$filter->add("Bar");
$filter->add("Baz");

print STDOUT ($filter->check("Bar") ? "Found" : "Not Found"), "\n";
print STDOUT ($filter->check("Bim") ? "Found" : "Not Found"), "\n";

exit;
[download]

jreades@sort:~>> ./test.pl
Use of uninitialized value in numeric gt (>) at Bloom/Filter.pm line 1
+26.
Argument "" isn't numeric in numeric eq (==) at Bloom/Filter.pm line 8
+6.
Argument "@" isn't numeric in numeric eq (==) at Bloom/Filter.pm line 
+86.
Found
Argument "" isn't numeric in numeric eq (==) at Bloom/Filter.pm line 8
+6.
Argument "" isn't numeric in numeric eq (==) at Bloom/Filter.pm line 8
+6.
Found
[download]

It's just possible that there's something wrong with the module itself, and I've emailed the author asking for any tips or tricks but I haven't heard back from him/her yet.

And yes, I do think that the approach is pretty neat -- when someone suggested it and I did some reading it leapt out as a very low-cost way to perform a high-cost operation. And, as you said, even taking a fairly high false-positive rate of 0.1% you still end up with a tiny fraction of your original search space.

I did notice the odd bias towards email addresses but figured it might not affect what I was trying to do. What algorithm would you suggest as an alternative for working with 12-digit numeric keys more efficiently?

TIA