Trippple Checks

[manfred4]

Originally Posted by VictordeHolland

He is referring to the optimal TF cut off point, between running TF and running CudaLucas on a GPU.
You are only saving 1 LL test with these factor finds and you have to do a bunch of them before finding a factor. In that time you could have done a LL on the GPU.

Right. I have no GPU, that could complete that test in 3 hours, but more like in (less than) 3*70 or 3*80 hours, which would be the average time to find a factor there.

[Anonuser]

Originally Posted by Madpoo

Awesome, thanks for that.

Here's an updated list that I think has all the latest stuff (requests for work, removed the stuff that's been factored or triple-checked) and I marked your TF work as completed.

I think petrw1's TF work on that first block is done... I believe he's doing double-checks on it now.

VictordeHolland had been doing TF work to higher bit levels. I don't know if he'd be interested in carrying it forward a few more bits than what you've done? Just tossing that idea out there.

I'll take the exponents between 40000000 and 55000000 in the updated list (TF only).

[Prime95]

Originally Posted by Madpoo

I haven't looked at all of them, but that last one is kind of funny... there are 3 results and one of them actually has the masked residue in the database itself (with the __ for the last byte). Weird.

The v4 database "lost" some LL results way back when. Something like, they appeared in the masked recent results web page but didn't get into the LL results table. So I took the masked LL results and entered them into the LL result database. It was a long time ago, so the details are a bit fuzzy. Anyway, that's how some masked results got in the database. I guess I allowed them to be used in verifying a double-check. More possible candidates for your triple checking.

I'm a little confused about some of them... I mean, George said he had to manually look at the residues to see if they were really matches, but I don't know what all that involved.

This one for example seemed odd since 2 of them with different residues were submitted by the same person:
http://www.mersenne.org/M13438079

That person also has a bad result in there. So who knows.

Yeah that was weird. An obviously bad residue was marked as good. I guess I erred somewhere in the manual process. I fixed the database.

When I check them in, there's a chance my result will be marked bad, depending on which existing residue it happens to try and match against.

For George, to work around this I'd recommend something in the code that matches residues that does more like:
where <residue> in (select distinct <residue> from xx where exponent=xyz)

Rather than whatever it might be doing which might be a: where residue=(select top 1 residue...)

I've patched the current code to not pull up any Myrman residues or residues ending in '__' when doing the "top 1" query. Let me know if that does not work.

I've also manually patched the database for the three example exponents you've posted.

[Madpoo]

Originally Posted by Prime95

I've patched the current code to not pull up any Myrman residues or residues ending in '__' when doing the "top 1" query. Let me know if that does not work.

I've also manually patched the database for the three example exponents you've posted.

I don't know if it's related, but I just checked in the last 47 LL results for those exponents and each one had an output like this:

processing: LL for M1373483
Warning: odbc_do(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near '/'., SQL state 37000 in SQLExecDirect in C:\inetpub\v5\v5server\0.95_database.inc.php on line 145
LL test successfully completes double-check of M1373483 CPU credit is 0.0613 GHz-days.

My result did get checked in though, and shows as a match, so the error it shows must be non-critical in that respect.

The ones I did last night didn't show that error and either got checked in as bad or good depending on which old one it happened to match with (I think only one more was marked bad... I can toggle it to verified state or if you'd prefer: it was http://www.mersenne.org/M3365707 )

I see now the changes you made to exclude the Myrman results, based on the app version id, and also ecxluding where the stored residue is masked. Hmm... that all looks fine to me...can't imagine where that error message I got started out.

I wonder if we could use that app version to somehow color code or do something on the exponent report page to indicate that, yes it's a weird residue that doesn't match the others, but that it's really okay.

FYI, I was getting stumped by the LIKE clause and its treatment of underscores... I used the syntax LIKE '%[__]' but yours is probably more explicitly awesome, specifying the escape character.

[Madpoo]

Originally Posted by Prime95

I've patched the current code to not pull up any Myrman residues or residues ending in '__' when doing the "top 1" query. Let me know if that does not work.

FYI, now that I know how to spot those special residues, there are still 34 examples where the mismatched results aren't due to one of them being that specific app version id.

Examples would be:
http://www.mersenne.org/M1048507
http://www.mersenne.org/M1397983
http://www.mersenne.org/M1398017

etc.
Some seem to have in common that the odd residue is from user "Dwayne Towell" and that first one has the odd one from Mayer.

The "Towell" app version id seems to be 26, and Mayer's in that one example is 17, if that helps at all.

So the 3 apps in question, including the Myrman app, are:
Mlucas,Ernst Mayer,v2.4c and earlier,(aka E)
Mac,John Sweeney,v1.4,(aka J3)
Nick Myrman,DWT,(aka N2)

Overall, in some exponents, that "Sweeney" app has it's results marked good, sometimes they're marked bad. Usually the ones marked good are pretty close to the other good residues, and when they're marked bad, they are very different from the good ones. I'm guessing it's just another app where it did it's residues slightly different than the Prime95 method, but close enough that you could eyeball them and tell?

Same thing with the "Mayer" app... they're generally very similar to the other good ones.

I also see mismatches from these apps (ids 19, 100):
Mlucas,Ernst Mayer,v2.5 and later,(aka E2)
Crandall,(aka X)

The only really odd one out was on that exponent http://www.mersenne.org/M3365707 where the mismatched result actually came from app #67: "Windows,Prime95,v16,(aka WS1)"

That's the one I mentioned I'd checked in last night and my result got marked bad because it matched against that first bad one.

So basically if I exclude those 5 app ID's which you seem to be aware of (17,19,26,32,100) there was only that one weird one.

All of them do have triple or more checks now, including my most recent check-ins which were manually done but use the latest Prime95 version.

EDIT: I'm going to check and see if there are any exponents where the ONLY matching residues come from those 5 particular app versions... if so it'd be worth checking in a result from a recent run. Otherwise if those are excluded in the SQL query and someone checks in a recent result, it wouldn't return anything. :)

[Prime95]

SQL Query modified with your suggestions.

[Madpoo]

Originally Posted by Madpoo

EDIT: I'm going to check and see if there are any exponents where the ONLY matching residues come from those 5 particular app versions... if so it'd be worth checking in a result from a recent run. Otherwise if those are excluded in the SQL query and someone checks in a recent result, it wouldn't return anything. :)

I found 32 exponents where the only "verified" results were from any of those 5 apps.

Some of them have results marked as bad so I'm wondering if those were results of a good residue not matching any of those funky ones.

They're mostly small exponents under 10M with just one slightly bigger one (M22023539)

I'm going to run all of those through Prime95... my results may end up getting marked as bad, but before we thought about manually marking any of them as good they should probably get double-checked by someone else to make sure there are 2 matching residues from a different app than those.

Once I've finished running all of them I'll spit out a list of the ones that need that kind of extra verification and someone else could hopefully volunteer to handle those? Might be all 32 but maybe less. Really, they're small enough that I bet I can knock them all out in a few hours on some beefy systems.

[Gordon]

Originally Posted by R.D. Silverman

So what? They were already known to be composite.

Finding small factors of Mersenne numbers already known to be composite is a waste of
time.

In your opinion maybe, in terms of the project - searching for a prime, yes.

Some of us though just like finding factors and want to see as many factored as is practically possible, and have sufficient GPU resources that we can throw a GTX-660 at it...and still clear ~50 DC TF tests a day via gpu72.

[Gordon]

Originally Posted by Madpoo

M3365707

Just out of interest I loaded that onto the 970, taking it one more bit (65-66) took exactly 7 minutes. I smell an interesting sub project of going right back to the lowest exponents and taking them all up to say 68 bits which for exponents in this range is just 42 minutes.

..and to head off RDS - yes it doesn't advance the project, but it's my electricity and I'll spend how *I* wish

[ATH]

Originally Posted by Madpoo

Once I've finished running all of them I'll spit out a list of the ones that need that kind of extra verification and someone else could hopefully volunteer to handle those? Might be all 32 but maybe less. Really, they're small enough that I bet I can knock them all out in a few hours on some beefy systems.

I can take those needing extra verification, but it will not be quick as my computer is far more botanical than beefy.

[Madpoo]

Originally Posted by Gordon

Just out of interest I loaded that onto the 970, taking it one more bit (65-66) took exactly 7 minutes. I smell an interesting sub project of going right back to the lowest exponents and taking them all up to say 68 bits which for exponents in this range is just 42 minutes.

..and to head off RDS - yes it doesn't advance the project, but it's my electricity and I'll spend how *I* wish

If you're serious about that, I can generate a list of exponents for you matching whatever criteria.

Like, if you set your cutoff points for "exponents below XXX I want to take to TF depth 68" and then "exponents up to YYY to depth 69" etc.

I can spit out a list of exponents that are not currently at whatever levels and send you the list. This *might* be something James at mersenne.ca could do, or GPU72 might have the reports you need to do the same basic thing.

For much smaller exponents, like below 1M, I have no idea if it would make any sense to factor them beyond where they are, like 501013 which has been factored to 61 bits. I mean, I haven't given any thought at all to what it would take to factor it higher or if it would be useful, etc.

61 bits appears to be the current "floor". All exponents that have had any factoring done at all have at least been TF'd to that depth.