The last log 151. Even smarter C-ving, towards a reverse sieve proposes 2 ideas to enhance the sieve and its generation. First, we can "fill" the holes in a histogram by computing well-chosen values that would disambiguate which hole is the desired one. But it's quite heavy...

The second idea is much more lightweight and it reuses values determined after a hole appears, because there is a garantee that it will be filled later. It's just a matter of "by which modulus". This opens the possibility of a "multipass" algorithm that reinforces itself over and over, pushing the avalanche further (until no data can help anymore). Added with the selected "proving" system of the last log, it promises to make a longer and better sieve, despite it missing more than half of the moduli as they increase. But the more sieving, the better, because "we never know".

The sieve_boost program now becomes sieve_turbo, as it recyles its results to refine past misses.

• Just like before, it scans the list of primes until the avalanche makes it clear that no result can be obtained.
• When a histogram has more than one hole, the pairs of holes are marked as "P" (probable) instead of "#".
• When a histogram is conclusive (there is only one "hole" left), the corresponding prime/base is "marked" (the entry is cleared in the list") to prevent a rerun later. The position of the holes are checked in the scoreboard and if one (or more) of the new determined "hits" matches a "P", this is turned into "#" (determined) and the whole scan of the primes starts again, with one more hint.

Of course this means that the output will be scrambled at the end but this is easily sorted later.

That looks like a good plan, with minimal computational cost compared to the other which implies actual computations.

The output of the inconclusive results should be output to feed into another program that computes even more orbits for a future rerun of the program.

.

.

.

OK in fact I have made it more complex than it looks...

Just run the program while it gets a result with a refined list of primes, and stop when a new pass doesn't yield more results. Case closed.

As for the further sieving : let's output a hundred of probable zeroes, and let another program compute the candidates and orbit() them.

.

.

.

Update :

So I tried the multipass system and..........

it doesn't work. It's not a bug though : it could work IF the data allowed it.

In fact the lack of data creates such a wall that there are no chances that a new entry is computed to fill a preceding hole.

So it does 2 passes and the second pass does nothing.

Sigh.

Now all I can do is create candidates and test them... That will be for another day.