I'd start with automated testing, I'm not 100% sure it holds for all cases with "holes".

update

in hindsight ... it's still producing false negatives:

That's what the algo does with [3, [1, 0, 0, undef, 0, 0, 1]

. . 1 0 0 ? 0 0 1 
0 0 1 0 0 1 0 0 2 0 0 1 0 0 1 0
    ^           *
[download]

That's how it should fit

. . . . . 1 0 0 ? 0 0 1 
0 0 1 0 0 1 0 0 2 0 0 1 0 0 1 0
          ^
[download]

Sorry!

If I read it correctly, you currently make a sieve of length 2 * range, centred around p^max. I think you need the length to be around 2 * (range + p^{max - 1}).

I don't understand the logic you're using with $max_pos to decide where in the sieve to match, and I'm not sure it's correct. But I'd be tempted to punt on that - make both sieve and input into strings as below, and use a regexp match.

  use List::Util qw{min};
  my @order = '0' .. '9', 'A' .. 'Z'; # range of 2^36 is probably enou
+gh

  sub to_string {
    my($max, $list) = @_;
    return join '', map {
      defined($_) ? $order[min($_, $max)] : '.'
    } @$list;
  }
[download]

first of all, the algorithm as it is now is only reliable if a hole doesn't hide a max. Otherwise you get false negatives like demonstrated here

You will need to cover that!

I have some efficient ideas, but no time right now.

( These kind of riddles cost me a lot of processing power I need elsewhere. :)

> make a sieve of length 2 * range

that's sufficient because range can always fit in that sliding window.

I shift the window to the right by p^max_known+n if positioning the first max means a negative sieve index.

It's important to realize that this can only happen with preceding holes covering a former max. Hence these holes will also ignore the position p^max+n in the sieve. °

> 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

Of course representation of holes, like \xFF or \x00 makes this more challenging, needing a second and

But I consider this premature optimization, you should first test the validity of the algorithm with arrays.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}

°) Maybe it's even not necessary to try successive n and you can just shift by p^max - this equals swapping the sequence to the second half.

update

... to come...

... OK ... It's important to understand that those shifts and other problems are only due to one or more holes covering an e >= max ...

Without holes the algorithm works as is!

Now one needs to list the possible cases, for e=max and e >max and shift accordingly by + p^e for all "dubious" holes till one has a pass or all failed.

There might be a simple solution like moving the first hole to p^max+1 and taking advantage of the fact that further collisions are not possible because of the constraints (first max) but I can't wrap my head around it.