Strategic Double Clicking

[ATH]

Originally Posted by Madpoo

If anyone is in the mood for some quad checks, there are a few where AirSquirrels and I have already done 2nd/3rd checks and mismatched (I'm betting mine is correct) and we need a quad checker.

I queued all 6.

[airsquirrels]

It is exciting to get to the bottom of the triple checks.

Hopefully one of these strategic DCs eventually leads to a missed prime!

[Madpoo]

Originally Posted by airsquirrels

It is exciting to get to the bottom of the triple checks.

Hopefully one of these strategic DCs eventually leads to a missed prime!

The way I reckon it, there's a 5% chance of a missed prime in there. LOL

(Okay, I know someone will say it's not really 5% or whatever the statistical error rate is, but then we don't really know where those sneaky primes are hiding so there's every reason to think there could be one between the current double-check threshold of 37,781,573 and M46-M48).

[ATH]

Originally Posted by Madpoo

If anyone is in the mood for some quad checks, there are a few where AirSquirrels and I have already done 2nd/3rd checks and mismatched (I'm betting mine is correct) and we need a quad checker.

Yours were correct but M48067783 was factored with P-1 before my test:
http://mersenne.org/M42183899
http://mersenne.org/M42222473
http://mersenne.org/M44695687
http://mersenne.org/M44695787
http://mersenne.org/M48067783
http://mersenne.org/M72647011

[Madpoo]

Originally Posted by ATH

Yours were correct but M48067783 was factored with P-1 before my test

Ah, thanks. That reminds me that I should run another query for things like that: where multiple tests have been run and there may be some good/bad results, but it was factored first. The good results are fine but the bad results should be marked bad.

That's the way it would normally work if a factor was found after it was verified, but if the factor is found first and then the LL test was verified later, all of the results get marked as "verified (factored)".

I think I looked for those a year ago, give or take, but there are probably a few new since then. No sense in letting the bad results slip by as if all was well.

[S485122]

Originally Posted by Madpoo

Ah, thanks. That reminds me that I should run another query for things like that: where multiple tests have been run and there may be some good/bad results, but it was factored first. The good results are fine but the bad results should be marked bad.

That's the way it would normally work if a factor was found after it was verified, but if the factor is found first and then the LL test was verified later, all of the results get marked as "verified (factored)".

I think I looked for those a year ago, give or take, but there are probably a few new since then. No sense in letting the bad results slip by as if all was well.

I am afraid that in the queries available to us, the status of the LL tests on Mersenne numbers for which a factor was found is just factored. One looses the information that the LL test was verified.

In my opinion, the exponent should have a status of factored, but the LL tests should retain their status of bad, unverified or verified.

Jacob

[Madpoo]

Originally Posted by S485122

I am afraid that in the queries available to us, the status of the LL tests on Mersenne numbers for which a factor was found is just factored. One looses the information that the LL test was verified.

In my opinion, the exponent should have a status of factored, but the LL tests should retain their status of bad, unverified or verified.

Jacob

I'd like to have some kind of "verified by LL but also factored" status as well. Maybe that's something George would be amenable to in the future.

LL tests have 5 distinct states:
unverified
verified
bad
suspect
factored

I guess it could even just leave the status alone when a factor is found, but I know for sure some queries and code on the site would need updating since it's depending on things working they way they are now for certain things. Which is why a new status might be easier to shoehorn in.

[S485122]

Originally Posted by Madpoo

...
I guess it could even just leave the status alone when a factor is found, but I know for sure some queries and code on the site would need updating since it's depending on things working they way they are now for certain things. Which is why a new status might be easier to shoehorn in.

I am not sure that it would disrupt things : the status of an exponent is something else than the status of an LL test. When there are LL tests with different residues, in the end some of them are marked as verified and the others are marked as bad. This means that the records of LL tests must have some field to store their status and do not derive their status from the exponent.

Of course it is easy to write this from my chair, I will not have a thing to do.

Jacob

[Madpoo]

Originally Posted by S485122

I am not sure that it would disrupt things : the status of an exponent is something else than the status of an LL test. When there are LL tests with different residues, in the end some of them are marked as verified and the others are marked as bad. This means that the records of LL tests must have some field to store their status and do not derive their status from the exponent.

Of course it is easy to write this from my chair, I will not have a thing to do.

When an result is reported in for any exponent, the server takes a look and determines what to do. If it's a first test, it merely adds that to the results and then it will make that same exponent available for a double-check (or another "first time" check if that first result was suspect).

Double+ checks get their residue compared to any previous results. If it's a match (and they have different shift counts), the matching pair get marked as good, the oddballs are marked bad. Doesn't matter if they were marked "unverified" or "suspect" in their previous unknown states, they're simply good (verified) or bad at that point.

Where it gets weird is when a factor is found for an exponent. If the exponent hasn't had any LL tests done at all, no worries. If one or more tests are still unverified, they get changed to a status of "factored", no matter what. If the exponent has been successfully double-checked, all "verified" results get changed to "factored" and I think "bad" results stay as bad? I'm not sure if that's automatic or if that's something that was done retroactively and would need to be done again.

I guess the idea here is that the *exponent* is factored but it doesn't make sense, and we lose some interesting data points, to mark older *results* as factored.

The trouble with doing any changes up front in that is there are many queries, reports, jobs, etc. that pay attention, for better or worse, to the fact that LL results for a factored exponent are treated special. They no longer get their residue masked because at that point it doesn't matter. Unassigned LL results for factored exponents are rejected as unnecessary (but assigned results are still accepted, more out of a sense of pity... it handles cases where a slow worker finally turned something in, and in the meanwhile some factoring poacher found a factor first and turned it in).

Some of the difficulties are mere quirks in the database and can probably be solved by merely adding additional states... states that reflect "yes, this exponent is factored, and oh, here's how the LL test itself looks". That way we can just update reports, code, etc. gradually and then update the data itself when all the other pieces are in place with minimal fuss.

I don't know what George's take is on all of that. The current system may work well enough for now, perhaps, and probably bigger fish to fry, but if he was cool with it I might take a peek and get a better idea of the work involved.

[GP2]

Originally Posted by Madpoo

Some of the difficulties are mere quirks in the database and can probably be solved by merely adding additional states... states that reflect "yes, this exponent is factored, and oh, here's how the LL test itself looks". That way we can just update reports, code, etc. gradually and then update the data itself when all the other pieces are in place with minimal fuss.

The most straightforward thing to do, I think, would be just to have two separate status fields: factored/not factored on the one hand, and unverified (unknown)/unverified (suspect)/verified (good)/verified (bad).

Or maybe implemented as three bit flags in a single field: a factored/not factored bit, a verified/unverified bit, and a good-nonsuspect / bad-suspect bit.

In principle, whether or not an exponent has been factored is entirely independent of LL test results. You could theoretically perform a redundant LL test on an exponent that's already been factored, just like you can perform a (third or higher) redundant LL test on an exponent that's already been double-checked.

[Madpoo]

Originally Posted by GP2

The most straightforward thing to do, I think, would be just to have two separate status fields: factored/not factored on the one hand, and unverified (unknown)/unverified (suspect)/verified (good)/verified (bad).

Or maybe implemented as three bit flags in a single field: a factored/not factored bit, a verified/unverified bit, and a good-nonsuspect / bad-suspect bit.

All true, but I'm more interested in whatever is easier to implement.

In principle, whether or not an exponent has been factored is entirely independent of LL test results. You could theoretically perform a redundant LL test on an exponent that's already been factored, just like you can perform a (third or higher) redundant LL test on an exponent that's already been double-checked.

True enough. In fact I did just that, doing a double or triple check for a bunch of (small) exponents that had one (or more, mismatching) tests done but a factor was found before it was ever verified. I didn't do a lot of those, just a few in cases where I thought it might help me figure out if the CPU in question on that first test was good or bad. I suppose you could say that a test like that isn't redundant at all... I mean, it doesn't do anything for saying if it's composite or not since we already know, but it is useful in determining system stability. I think I already got all of the easy pickings in there where there were 2 mismatched LL results plus a factor found later. Might be some stragglers in the larger sizes that I didn't feel like tussling with.