> > make both sieve and input into strings as below, and use a regexp match.

> Not sure I understand, but the fastest way to compare two byte arrays is to xor the strings, a range of 256 or even 128 exponents should be sufficient

We don't have two byte arrays, we have one array with possible holes and one without. And as I mentioned just before the quote you show: I'm not yet convinced of the correctness of your approach to picking the point in the sieve to compare against. Using a regexp removes the need to know what the starting point should be, has '.' as a handy mechanism for matching the holes, and won't go wrong if a hole happens to match something maximal.

So I'm suggesting that for the (3, [1, 0, 0, undef, 0, 0, 1]) example, a solution that ends with return +("010010020010010" =~ /100.001/) ? 1 : 0 would be a good efficient approach as long as the prep to make the string (once) and the pattern (each call) is fast enough. I'd need to sit down with pen and paper to work out exactly what length of string is required for a given (p, range): I'm not confident I know right now what it should actually be.