I don´t know if it´s and after-issue of the contest, but I was *really* bored and had a look at the PSP sieving range statistics. I found really strange results. Normally, about 20-30 factors are found per range (1T wide range)... ok, may be 40... that´s the normal thing up to range 2850something.

But, just after, there are a few of the ranges (just, I think, after the contest) with many, many, many more, in the 100-200 area. 2895 to 2896T, 2896 to 2897T, 2909 to 2910T etc..

Ok, you may argue that factors have not to be equaly distributed, but such diferences are... troubling. No range with more than 100 factors before, and suddently a "sweet fator spot"?

But what is weird is, range 2911 to 2912T with ***604*** factors (WTF?) and still with non finished WU´s...

PSP sieve WU´s are not double checked, aren´t they? What if we are reporting false factors and spoil the whole PSP or SoB projects? Could be just double check the WU with factors in the future?

... or could the DB issue had something to do?
... or is the table I´m just right now looking at corrupted?
... what yellow smells like?

ok, any clever guys, please, calm my anxiety....

Thanks for the comments and questions. In short, yes, we are aware of the PSP sieving range errors. Yes, it is a corrupted table. And yes, it was caused by the database issue.

Rest assured that there is no chance that PG can spoil the PSP or SoB projects. Also, there is no reason to run double checks on sieve WU's as the sieve programs are quite solid. The only chance of an error is if the sieve misses a factor...which is "extremely" rare. In that case, it only means that there will be an extra LLR test (2 since we're double checking LLR) on the candidate that had the missed factor.

Additionally, both PSP and SoB have verification scripts that confirm whether a factor is valid. If an invalid factor was submitted, these scripts would quickly identify it. It's time consuming to find factors, but easy to confirm them once found.

I hope this answers your questions.

Basically, what has happened is that multiple validators running at the same time registered found factors multiple times into the database. Right now we have some factors registered A LOT of times: two 231 times, one 219 times, one 218 times, one 120 times and a few less than 100 times.

I will have to cook up a script to repair it...