Certificate : For all indents and purposes

[EdH]

Originally Posted by pakaran

Since we've both got the validator quite busy, and to avoid duplication with myself, I'm taking the 20 numbers starting with 2501 dd.

Those might be being done by Jayder.

How far into 2200 did you get? I just picked up a batch from 2220 upward. I'll run those today if you 're not working there.

[pakaran]

Originally Posted by EdH

Those might be being done by Jayder.

How far into 2200 did you get? I just picked up a batch from 2220 upward. I'll run those today if you 're not working there.

I didn't even get all the way to 1k.

I'll stop the larger numbers. Then I'll recheck the list, and keep going below 2200. We recheck if you consider going below that point, or if I go above it. While this is my last comment, I hold no reservations; I only did two numbers at 2501. Reservation to be made shortly...

[pakaran]

Taking the 500 numbers starting at 300 dd.

[Jayder]

Maybe I should clarify that I am working upwards from 2500.

Found a composite that refuses to be made so by the database: http://factordb.com/index.php?id=1100000000781996714

[EdH]

I am now working at 2184 up to about 2220. There are a few stragglers left between 2220 and 2500 that I haven't picked up yet. I will revisit later after the bulk of the area is cleared.

[paulunderwood]

Originally Posted by Jayder

Found a composite that refuses to be made so by the database: http://factordb.com/index.php?id=1100000000781996714

I am not sure what "##" means, but most likely this is a Carmichael number. It fails my own test which incorporates a Lucas test -- I guess Primo rejected it because it does a BPSW as a pre-test.

Edit: It is not 2-PRP. So factorDB is faulty.

[Batalov]

In factordb terms it means

Operator   Description                          Example
##         Product first n primes (postfix)     44##+1

So it is = (776*5897#+1)/92857

[axn]

This is caused by a difference in interpretation of ## by factordb & PFGW,

PFGW is interpreting this is as (776*776#+1)/92857 (the division wouldn't be exact. PFGW takes the quotient). This is a 322 digit prime.

[schickel]

Originally Posted by pakaran

Since we've both got the validator quite busy, and to avoid duplication with myself, I'm taking the 20 numbers starting with 2501 dd.

It's been my experience that if you have certificates in the pipeline on the server being verified, you can download more candidates from the current range being processed and you won't receive the queued numbers.

[EdH]

Originally Posted by EdH

I am now working at 2184 up to about 2220. There are a few stragglers left between 2220 and 2500 that I haven't picked up yet. I will revisit later after the bulk of the area is cleared.

How disappointing! I find that I have deleted all those certificates prior to my attempt to upload them to the db.

In Other News, I'm cleaning up the stragglers just below 2500 today. I found 19 composites among the crowd and have corrected them in the db. I wrote some scripts to identify them and open their pages for correction. That work is probably why I wasn't paying enough attention to the certificates...

[pakaran]

Originally Posted by Jayder

Maybe I should clarify that I am working upwards from 2500.

Found a composite that refuses to be made so by the database: http://factordb.com/index.php?id=1100000000781996714

I am sorry about that, I suspect I "poached" those two numbers from you.

I'm continuing to work "up" from 300 dd. Last pass (starting Saturday evening, US time), my single 2/4 core Core 5 laptop made a significant dent in the "barrier" from 989 to 995 dd. The pass I've just started will likely go up into the quadruple digits in roughly another day (a fair number of new numbers added, plus the rest of the barrier).