Why different shift counts are important

[Madpoo]

For whatever reason, there were a couple hundred exponents that had matching residues, but their shift counts were the same so they were (fortunately) kept as unverified.

I think we were figuring these were mostly mistaken, as a result of someone trying to turn in the same thing twice by accident... some may have come in manually via the emails George used to get.

At any rate, the system in place now looks for the same shift count and I don't think it even accepts it, so mostly the ones in the data are older/smaller. I took it upon myself to do the DC work on these, and they've all matched so far except this one. So I'm glad different shifts are required.

M35385769

[retina]

Originally Posted by Madpoo

For whatever reason, there were a couple hundred exponents that had matching residues, but their shift counts were the same so they were (fortunately) kept as unverified.

I think we were figuring these were mostly mistaken, as a result of someone trying to turn in the same thing twice by accident... some may have come in manually via the emails George used to get.

At any rate, the system in place now looks for the same shift count and I don't think it even accepts it, so mostly the ones in the data are older/smaller. I took it upon myself to do the DC work on these, and they've all matched so far except this one. So I'm glad different shifts are required.

M35385769

If you are saying what I think you are saying then that would point to a bug in the software. Having two different people get the same incorrect residue is extremely unlikely if it is due to errors on their respective systems. So the alternative explanation is that the software has a bug.

[LaurV]

Originally Posted by retina

If you are saying what I think you are saying then that would point to a bug in the software. Having two different people get the same incorrect residue is extremely unlikely if it is due to errors on their respective systems. So the alternative explanation is that the software has a bug.

I don't think he's saying what you think he is saying. He says that somehow, someone managed to register that test two times. If you look into the history, some anon user tried to register the result many times in 2006, when the shift was already implemented, IIRC. There is a very small (null) probability someone else got the same exponent AND the same shift to test it, therefore I assume that the 2*anon, S53xxx, and John whatever, are the same user. We can however check the result produced by P95 (actual version) if we know the shift (I can do that, run a test with a pre-determined shift, by playing with the initial checkpoint file, but George may have a better way) and we see if there is some bug still there, as you said. Should we follow into this path?

[Prime95]

If you look at the full results line, the matching shift count were sent by a different user id, but the same computer name. This person was simply a victim of an old prime95 bug where the client "lost" the user id, contacted the server and was assigned a new user id, and subsequently resent the results.txt file (there was client code that would do this too).

So.... nothing nefarious going on here.

[Mark Rose]

Originally Posted by Madpoo

At any rate, the system in place now looks for the same shift count and I don't think it even accepts it, so mostly the ones in the data are older/smaller. I took it upon myself to do the DC work on these, and they've all matched so far except this one. So I'm glad different shifts are required.

M35385769

Mine.

[Madpoo]

Originally Posted by Prime95

If you look at the full results line, the matching shift count were sent by a different user id, but the same computer name. This person was simply a victim of an old prime95 bug where the client "lost" the user id, contacted the server and was assigned a new user id, and subsequently resent the results.txt file (there was client code that would do this too).

So.... nothing nefarious going on here.

^^^ yeah, that. Just a weird result of the same result being checked in twice (in some cases the same thing had been checked in more than twice, I think as many as 5 or 6 times).

My point was that I'm glad the shift-count check is there otherwise it may have accidentally been accepted.

By the way, I think at some point I went through and looked for verified work where the shift count was absent (before that feature was introduced) and I think they'd all been triple-checked already, for whatever that's worth. I might check again since it's on my brain, but I'm pretty sure that's taken care of.

[Mark Rose]

Originally Posted by Mark Rose

Mine.

We matched, as expected.