`StreamingSieve::prime_pi` panics on `15 << i` with `i >= 16`

[aedoq]

So I'm being annoying again, the title says it all:

use primal::StreamingSieve;
fn main() {
    dbg!(StreamingSieve::prime_pi(15 << 16));
}

panics:

Backtrace

``` thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /home/aedoq/.cargo/registry/src/github.com-1ecc6299db9ec823/primal-sieve-0.3.4/src/streaming/mod.rs:125:46 stack backtrace: 0: rust_begin_unwind at /rustc/27eb6d7018e397cf98d51c205e3576951d766323/library/std/src/panicking.rs:584:5 1: core::panicking::panic_fmt at /rustc/27eb6d7018e397cf98d51c205e3576951d766323/library/core/src/panicking.rs:142:14 2: core::panicking::panic at /rustc/27eb6d7018e397cf98d51c205e3576951d766323/library/core/src/panicking.rs:48:5 3: core::option::Option::unwrap at /rustc/27eb6d7018e397cf98d51c205e3576951d766323/library/core/src/option.rs:775:21 4: primal_sieve::streaming::StreamingSieve::prime_pi at /home/aedoq/.cargo/registry/src/github.com-1ecc6299db9ec823/primal-sieve-0.3.4/src/streaming/mod.rs:125:33 5: _501::main at ./src/bin/501.rs:3:10 6: core::ops::function::FnOnce::call_once at /rustc/27eb6d7018e397cf98d51c205e3576951d766323/library/core/src/ops/function.rs:248:5 ```

[cuviper]

No need to apologize (or think yourself annoying) for finding legitimate bugs!

I'm curious how you found this... +/- 1 is just fine, so it would seem to be a particular edge case.

[cuviper]

Oh I see, that value (15 << 16) happens to be SEG_LEN.

[cuviper]

@aedoq I merged a fix, but haven't published yet -- should I wait for you to hammer on this some more? :sweat_smile:

[cuviper]

Meh, I went ahead and published 0.3.5. (But I forgot about the protected branch, so now #52 is merging that.)

[aedoq]

I'm curious how you found this...

Initially I wanted to solve ProjectEuler problem 501 but I was getting inconsistent results and found this while checking pre-computed values of prime_pi <= 1_000_000.

The implementation in num_prime is now also fixed, so I cross-checked the values and they agree up to 2^22 and for ~100 random values up to 2^35, so I think it's safe to say they're both correct now.

[aedoq]

I spoke too soon, there's something else going on either with my code, primal, or num_prime... I'll investigate a bit more

[aedoq]

It was my code. Both primal and num_prime are working fine