[QUOTE=Batalov;454579]The proverbial disbelievers, right? :rolleyes:[/QUOTE]
...and it wasn't me :leaving: 
[M]M12569[/M] is the 313th known fullyfactored or probablyfullyfactored Mersenne number.
Anyone want to run Primo on it? 
[QUOTE=GP2;456219][M]M12569[/M] is the 313th known fullyfactored or probablyfullyfactored Mersenne number.
Anyone want to run Primo on it?[/QUOTE] :jcrombie: I will do it 
[QUOTE=paulunderwood;456225]:jcrombie: I will do it[/QUOTE]
Done: [URL="http://www.factordb.com/index.php?id=1100000000919047896"]factorDB entry[/URL]. It is too small for UTM's top20 Mersenne cofactors. :cool: 
[URL="https://www.mersenne.ca/exponent/174533"]M174533[/URL] is the 314th known Mersenne number probably fully factored.

Been a long time since I fiddled with the Mcofactors, but a gander at the Top 20 page shows me that the largest 5 I posted (as PRPs) to the old mersenne mailing list in October 1997 have all been proven in recent years.
p 14561 8074991336582835391. p4365 17029 418879343. p5118 28759 226160777. p8649 28771 104726441. p8653 32531 65063.25225122959. p9778 Not to seem greedyforcredit, but a link to the aforementioned mailinglist posting might be in order for the References section. I will fwd link to this post to Chris C. after it goes up. 
[QUOTE=alpertron;460355][URL="https://www.mersenne.ca/exponent/174533"]M174533[/URL] is the 314th known Mersenne number probably fully factored.[/QUOTE]
[CODE] time ../../coding/gwnum/lucasPRP M174533cofactor 1 2 174533 1 Lucas testing on x^2  4*x + 1 ... Is Lucas PRP! real 0m17.580s user 0m32.212s sys 0m19.140s [/CODE] [URL="http://www.mersenneforum.org/showpost.php?p=435694&postcount=14"]Reference program[/URL] 
[QUOTE=ewmayer;460386]Not to seem greedyforcredit, but a link to the aforementioned mailinglist posting might be in order for the References section. I will fwd link to this post to Chris C. after it goes up.[/QUOTE]
I think [URL="http://primes.utm.edu/top20/page.php?id=49"]Chris Caldwell's page[/URL] gives credit to the person who ran the prover program (such as Primo), i.e. the person who actually proved the cofactor was prime rather than the person who discovered that it was a probable prime. Consistent with this, he only posts exponents with provenprime cofactors, so his list tops out at M63703 even though the record probableprime cofactor is for M5240707. Even today proving primality for cofactors of an exponent of the size of M32531 takes a few weeks, so I assume it was not feasible back in 1997. 
[QUOTE=GP2;460410]Even today proving primality for cofactors of an exponent of the size of M32531 takes a few weeks, so I assume it was not feasible back in 1997.[/QUOTE]
It doesn't take a few weeks. In 2017, one can have it done in a day or two and at a cost of under twenty bucks. All you need is a 32core AWS spot instance (there are zones where it is under $10/day in spot) and need to know how to run X over ssh (which is a googlable task). Even a 15,600digit number (~8 times more core time) is doable this way without too much trouble. In 1997, of course, this was not feasible or cheap. 
[QUOTE=GP2;460410]I think [URL="http://primes.utm.edu/top20/page.php?id=49"]Chris Caldwell's page[/URL] gives credit to the person who ran the prover program (such as Primo), i.e. the person who actually proved the cofactor was prime rather than the person who discovered that it was a probable prime.
.[/QUOTE] The prover gets credit with the option of sharing it with the PRP'er/factorer :smile: 
Yes, that's correct. For example I found that the cofactor of M19121 is PRP but I'm listed at [url]https://primes.utm.edu/primes/page.php?id=119721[/url] even though I have not ran the Primo primality program.

[QUOTE=GP2;460410]Even today proving primality for cofactors of an exponent of the size of M32531 takes a few weeks, so I assume it was not feasible back in 1997.[/QUOTE]
Back then Francois Morain and I set the record for generalprime proving with the ECPP proof of the M7331 cofactor, and that required several monthslong attempts on an Alpha workstation, separated by a crucial bugfix by Morain to his ECPP code. So yeah, M32531 was way out of reach of anything below supercomputer hardware, and IIRC Morain's code was not capable, anyway. 
[QUOTE=paulunderwood;460434]The prover gets credit with the option of sharing it with the PRP'er/factorer :smile:[/QUOTE]
[QUOTE=alpertron;460450]Yes, that's correct. For example I found that the cofactor of M19121 is PRP but I'm listed at [url]https://primes.utm.edu/primes/page.php?id=119721[/url] even though I have not ran the Primo primality program.[/QUOTE] Ah OK. Personally I choose to disclaim any credit. 
[QUOTE=alpertron;379831]Using the formulas above I computed the expected numbers of PRP to be found in different ranges. Notice that most Mersenne numbers are not factored up to these bounds because the factorization stopped when the first prime factor was found.
[CODE] Range Known PRPs 25 digits 30 digits 35 digits  1K2K 45 14 17 20 2K5K 26 17 20 24 5K10K 16 12 14 16 10K20K 10 11 13 15 20K50K 8 13 16 18 50K100K 7 9 11 13 100K200K 5 9 10 12 200K500K 5 11 13 15 500K1M 3 8 9 11 1M2M 3 7 9 10 2M3M 0 4 5 6 3M4M 0 3 3 4 4M5M 0 2 3 3 5M10M 0 7 8 9 [/CODE][/QUOTE] The above was posted in August 2014. It represents a prediction, made at the time, about the secondlargest factor of fullyfactored (or probablyfullyfactored) Mersenne exponents. Note that the actual largest factor, of course, is an enormous cofactor which is omitted from our factor data tables. The above table tries to predict the number of FForPFF exponents in a given range whose secondlargest factor has less than 25 digits (or is that supposed to be less than or equal to 25 digits?), less than 30 digits, less than 35 digits. Since 2014, more PRPs have been discovered, but also more ECM has been done: All exponents up to 2389 have been ECM tested to t=50 All exponents up to 2591 have been ECM tested to t=45 All exponents up to 8017 have been ECM tested to t=40 All exponents up to 14341 have been ECM tested to t=35 All exponents up to 103067 have been ECM tested to t=30 Also, PRP testing has been done up to 6M so far. That means that no new PRP cofactors (i.e., no new FForPFF exponents) will be discovered under 6M unless as a result of the discovery of new factors. However, since ECM has been done up to t=30 for exponents up to 100K and a bit beyond, we would expect very few if any new factors smaller than 25 digits to be discovered in this range, and in any case, any individual factor discovery has very low probability of resulting in a new PRP discovery. In other words, we already have definitive data for the top part of the "25 digits" column in the table above, and can compare it to the predictions. I took a preliminary look, and the actual numbers seem to be running consistently below the predicted numbers. Before posting the actual numbers, I'd like to clarify whether "25 digits" in the prediction meant "less than 25" or "less than or equal to 25". 
[QUOTE=GP2;460699]Before posting the actual numbers, I'd like to clarify whether "25 digits" in the prediction meant "less than 25" or "less than or equal to 25".[/QUOTE]
I believe it is 25 digit or less (i.e. < 10^25). 
We can create the table below, which reflects known PRPs rather than predicted numbers. For an explanation of the meaning of the numbers, see my post above.
The numbers towards the bottom and towards the rightmost (35 digits) column will likely increase over time, since PRP testing and ECM testing for new factors is incomplete. However, the number towards the top and towards the leftmost (25 digits) column are unlikely to increase. For example, all exponents in the 1K to 2K range have been ECM tested to t=50, so we aren't going to find any new factors of 25 digits or less. So the current values are the final values. The numbers do seem to be below the predicted values. [CODE] Range Known PRPs 25 digits 30 digits 35 digits  1K–2K 52 11 12 14 2K–5K 26 10 14 21 5K–10K 17 11 12 14 10K–20K 13 6 8 9 20K–50K 12 6 9 10 50K–100K 9 6 8 9 100K–200K 8 6 7 8 200K–500K 8 8 8 8 500K–1M 6 6 6 6 1M–2M 4 4 4 4 2M–3M 1 1 1 1 3M–4M 1 1 1 1 4M5M 2 2 2 2 5M–10M 1 1 1 1 [/CODE] [B]1K–2K[/B] 25 digits or less: [M]1049[/M] [M]1063[/M] [M]1103[/M] [M]1223[/M] [M]1289[/M] [M]1303[/M] [M]1327[/M] [M]1459[/M] [M]1487[/M] [M]1531[/M] [M]1637[/M] 2630 digits: [M]1307[/M] 3135 digits: [M]1097[/M] [M]1997[/M] more: [M]1009[/M] [M]1013[/M] [M]1019[/M] [M]1021[/M] [M]1031[/M] [M]1033[/M] [M]1039[/M] [M]1051[/M] [M]1061[/M] [M]1069[/M] [M]1087[/M] [M]1091[/M] [M]1093[/M] [M]1109[/M] [M]1117[/M] [M]1123[/M] [M]1129[/M] [M]1151[/M] [M]1153[/M] [M]1163[/M] [M]1171[/M] [M]1181[/M] [M]1187[/M] [M]1193[/M] [M]1201[/M] [M]1301[/M] [M]1321[/M] [M]1361[/M] [M]1373[/M] [M]1409[/M] [M]1427[/M] [M]1543[/M] [M]1553[/M] [M]1559[/M] [M]1657[/M] [M]1693[/M] [M]1783[/M] [M]1907[/M] [B]2K–5K[/B] 25 digits or less: [M]2699[/M] [M]2837[/M] [M]2927[/M] [M]3041[/M] [M]3359[/M] [M]3547[/M] [M]3833[/M] [M]4127[/M] [M]4243[/M] [M]4751[/M] 2630 digits: [M]2251[/M] [M]2447[/M] [M]2909[/M] [M]3079[/M] 3135 digits: [M]2069[/M] [M]2311[/M] [M]2383[/M] [M]2677[/M] [M]3259[/M] [M]4729[/M] [M]4871[/M] more: [M]2087[/M] [M]2243[/M] [M]2381[/M] [M]2549[/M] [M]4219[/M] [B]5K–10K[/B] 25 digits or less: [M]5087[/M] [M]5227[/M] [M]5689[/M] [M]6883[/M] [M]7039[/M] [M]7331[/M] [M]7417[/M] [M]7673[/M] [M]8849[/M] [M]9697[/M] [M]9733[/M] 2630 digits: [M]6043[/M] 3135 digits: [M]7757[/M] [M]9901[/M] more: [M]5233[/M] [M]6199[/M] [M]6337[/M] [B]10K–20K[/B] 25 digits or less: [M]10007[/M] [M]11813[/M] [M]12451[/M] [M]14561[/M] [M]14621[/M] [M]17029[/M] 2630 digits: [M]17683[/M] [M]19121[/M] 3135 digits: [M]10211[/M] more: [M]10169[/M] [M]10433[/M] [M]11117[/M] [M]12569[/M] [B]20K–50K[/B] 25 digits or less: [M]20887[/M] [M]28759[/M] [M]28771[/M] [M]29473[/M] [M]32531[/M] [M]41263[/M] 2630 digits: [M]25243[/M] [M]35339[/M] [M]41521[/M] 3135 digits: [M]41681[/M] more: [M]25933[/M] [M]26903[/M] [B]50K–100K[/B] 25 digits or less: [M]57131[/M] [M]58199[/M] [M]63703[/M] [M]82939[/M] [M]86371[/M] [M]87691[/M] 2630 digits: [M]84211[/M] [M]86137[/M] 3135 digits: [M]53381[/M] [B]100K–200K[/B] 25 digits or less: [M]106391[/M] [M]130439[/M] [M]136883[/M] [M]157457[/M] [M]173867[/M] [M]175631[/M] 2630 digits or less: [M]174533[/M] 3135 digits: [M]151013[/M] [B]200K–500K[/B] 25 digits or less: [M]221509[/M] [M]270059[/M] [M]271211[/M] [M]271549[/M] [M]406583[/M] [M]432457[/M] [M]440399[/M] [M]488441[/M] [B]500K–1M[/B] 25 digits or less: [M]576551[/M] [M]675977[/M] [M]684127[/M] [M]696343[/M] [M]750151[/M] [M]822971[/M] [B]1M–2M[/B] 25 digits or less: [M]1010623[/M] [M]1168183[/M] [M]1304983[/M] [M]1790743[/M] [B]2M–3M[/B] 25 digits or less: [M]2327417[/M] [B]3M–4M[/B] 25 digits or less: [M]3464473[/M] [B]4M–5M[/B] 25 digits or less: [M]4187251[/M] [M]4834891[/M] [B]5M–10M[/B] 25 digits or less: [M]5240707[/M] 
The 315th in the list is: [URL="http://www.mersenne.ca/exponent/611999"]M611999 = 18464214225958267477777390354183 * PRP184199[/URL]

[QUOTE=alpertron;460879]The 315th in the list is: [URL="http://www.mersenne.ca/exponent/611999"]M611999 = 18464214225958267477777390354183 * PRP184199[/URL][/QUOTE]
FWIW [CODE]time ../../coding/gwnum/lucasPRP M611999cofactor 1 2 611999 1 Lucas testing on x^2  9*x + 1 ... Is Lucas PRP! real 2m21.692s user 5m2.932s sys 2m41.120s [/CODE] 
Sometime during Aug 31/Sep 1, a P68 was reported for [URL="http://www.factordb.com/index.php?query=M1471"]M1471[/URL], completing its factorization, making it #316
EDIT: The cofactor is a proven prime, so mersenne.ca status can be changed from PRP to P 
[QUOTE=axn;466979]Sometime during Aug 31/Sep 1, a P68 was reported for [URL="http://www.factordb.com/index.php?query=M1471"]M1471[/URL], completing its factorization, making it #316
EDIT: The cofactor is a proven prime, so mersenne.ca status can be changed from PRP to P[/QUOTE] OK, it now shows as a proven prime at mersenne.ca, based on the certificate at factordb.com The new factor showed up at FactorDB and at mersenne.ca, but not at mersenne.org... presumably mersenne.ca and mersenne.org exchange data both ways daily, so it would get there eventually? But I decided to manually report it to mersenne.org anyway, just to be sure... "Insufficient information for accurate CPU credit. For stats purposes, assuming factor was found using ECM with B1 = 50000. CPU credit is 0.0000 GHzdays." If the actual discoverer is a GIMPS user, maybe the database can be adjusted. 
[QUOTE=axn;466979]Sometime during Aug 31/Sep 1, a P68 was reported for [URL="http://www.factordb.com/index.php?query=M1471"]M1471[/URL], completing its factorization, making it #316
EDIT: The cofactor is a proven prime, so mersenne.ca status can be changed from PRP to P[/QUOTE] It occurred to me to run a screenscraping script to collect all Mersenne exponents under 10,000 known to FactorDB, and crosscheck them with the GIMPS database. I found one more new factor there: M[M]1489[/M] has a factor: 95909518295775374166321292697000685895150503357477127 (53 digits) It was [URL="http://factordb.com/index.php?id=1100000000956003192"]reported (by who?) to FactorDB on August 17[/URL]. The remaining 295digit cofactor is composite, however. Does anyone know who this person is, who is finding large new factors for very small Mersenne exponents, independently of GIMPS. Just a month ago, I ran a systematic crosscheck of exponents under 1 million (prompted by [URL="http://mersenneforum.org/showthread.php?t=22501"]this thread[/URL]), and synchronized the data on both FactorDB and GIMPS. Obviously it will be worthwhile to keep checking FactorDB every few weeks, for the very small exponents at least, to see if new ones keep cropping up. 
[QUOTE=GP2;467558]Does anyone know who this person is, who is finding large new factors for very small Mersenne exponents, independently of GIMPS.[/QUOTE]
Have you tried contacting SSW? 
[QUOTE=xilman;467563]Have you tried contacting SSW?[/QUOTE]
No, but these exponents are a tad larger than the Cunningham project limit. 
[QUOTE=GP2;467558]
M[url=https://www.mersenne.org/report_exponent/?exp_lo=1489&full=1]1489[/url] has a factor: 95909518295775374166321292697000685895150503357477127 (53 digits) It was [URL=http://factordb.com/index.php?id=1100000000956003192]reported (by who?) to FactorDB on August 17[/URL]. The remaining 295digit cofactor is composite, however. Does anyone know who this person is, who is finding large new factors for very small Mersenne exponents, independently of GIMPS. [/QUOTE] [quote]20170911 kkmrkkblmbrbk FECM Factor: 95909518295775374166321292697000685895150503357477127[/quote] Post #38 on page 4 of the thread [url=http://www.mersenneforum.org/showthread.php?t=21115&page=4]P1 factoring attempts at smallestremaining Mersenne numbers with no known factors[/url] might give a clue. 
[QUOTE=Dr Sardonicus;467581]Post #38 on page 4 of the thread [url=http://www.mersenneforum.org/showthread.php?t=21115&page=4]P1 factoring attempts at smallestremaining Mersenne numbers with no known factors[/url] might give a clue.[/QUOTE]
OK, except these are not exponents with no known factors. In fact, M[M]1471[/M] is now fully factored and M[M]1489[/M] is now 34% factored and the remaining composite cofactor is well within range of NFS. So, if anything, the mystery person might be trying to find "last factors" rather than first factors. Also, anyone that contributes to these forums would surely manually report any new finds to PrimeNet, which our mystery person is not doing. 
[QUOTE=GP2;467589]...and M[M]1489[/M] is now 34% factored and the remaining composite cofactor is well within range of NFS. [/QUOTE]
How do you figure? You said the cofactor is 295 digits, right? So this is either GNFS295 on the remaining cofactor, or SNFS on the original 1489bit number. Both would be world records. 
[QUOTE=VBCurtis;467592]How do you figure? You said the cofactor is 295 digits, right? So this is either GNFS295 on the remaining cofactor, or SNFS on the original 1489bit number.
Both would be world records.[/QUOTE] Yes the cofactor is 295 digits, or 977 bits. I either had a brain freeze or I didn't know what I was talking about. Pick the most charitable explanation. 
[QUOTE=VBCurtis;467592]How do you figure? You said the cofactor is 295 digits, right? So this is either GNFS295 on the remaining cofactor, or SNFS on the original 1489bit number.
Both would be world records.[/QUOTE] to be fair other than primes the cofactor can't divisors up to a 106 digit number otherwise the composite divisor would have to divide by one of the primes already given or a prime below the last divisor shown. 
[QUOTE=science_man_88;467595]to be fair other than primes the cofactor can't divisors up to a 106 digit number otherwise the composite divisor would have to divide by one of the primes already given or a prime below the last divisor shown.[/QUOTE]
How do you figure? I failed to parse your runon. Also, you mean 106 bits, rather than digits, amirite? What does "other than primes the cofactor can't divisors" mean? The cofactor can't have divisors other than primes? eh? Mostly I'd like to know where you got 106 digits, but a translation of the rest would be appreciated. 
[QUOTE=GP2;467569]No, but these exponents are a tad larger than the Cunningham project limit.[/QUOTE]Nonetheless, I know Sam collects factors larger than the official limits (I once sent him some Aur. base3 factors which he later used in an extension to that table) and I also know he keeps in contact with others who factor such things.

[QUOTE=science_man_88;467595]to be fair other than primes the cofactor can't divisors up to a 106 digit number otherwise the composite divisor would have to divide by one of the primes already given or a prime below the last divisor shown.[/QUOTE]I can't parse that. What?

the highest known factor right now, is about 53 digits. Any composite below it's square (106 digits, according to PARI/GP.) , would have to contain an earlier factor, if the factors up to that point are complete. so it's only primes up to the 106 digits of that square that can divide ( and assuming the factorization is complete up until that factor, above that factor as well).

[QUOTE=GP2;467589]...So, if anything, the mystery person might be trying to find "last factors" rather than first factors.
Also, anyone that contributes to these forums would surely manually report any new finds to PrimeNet, which our mystery person is not doing.[/QUOTE] Since about August 3, 2017, factors of 2^n1 have been added to FactorDB for most or all of n \in 1501, 1529, 1529, 1563, 1563, 1507, 1497, 1591, 1457, 1595, 1629, 1687, 1711, 1859, 1959, 1963, 1445, 1479, 1491, 1467, 1465, 1441, 1489, 1595, 1471, 1445, and 1525. Only two of those have prime "n". I downloaded some factors from jcrombie's factors.zip file into my own tiny database, and then uploaded some of my new factors to factordb. (I don't have a good record, but I see something around a half dozen to a dozen where the timestamp of the factorization in my database is earlier than the timestamp in factordb, and that doesn't include either of the Mersenne numbers.) It seems as though one or more other people are working on nearCunningham numbers. Maybe the two Mersenne numbers were just a coincidence. ryanp acknowledges factoring a couple of these in the ElevenSmooth thread. 
[QUOTE=GP2;467589]OK, except these are not exponents with no known factors. In fact, M[M]1471[/M] is now fully factored and M[M]1489[/M] is now 34% factored and the remaining composite cofactor is well within range of NFS. So, if anything, the mystery person might be trying to find "last factors" rather than first factors.
Also, anyone that contributes to these forums would surely manually report any new finds to PrimeNet, which our mystery person is not doing.[/QUOTE] The clue I referred to in my post, was to the identity of the user kkmrkkblmbrbk 
[QUOTE=science_man_88;467621]the highest known factor right now, is about 53 digits. Any composite below it's square (106 digits, according to PARI/GP.) , would have to contain an earlier factor, if the factors up to that point are complete. so it's only primes up to the 106 digits of that square that can divide ( and assuming the factorization is complete up until that factor, above that factor as well).[/QUOTE]
"If we know all factors below n digits, then any factor smaller than 2n1 digits that we find next must be prime." 1. How is this helpful in any way? 2. Do you have even the slightest grasp of ECM to realize that finding a factor of, say, 53 digits does *nothing* to tell you there aren't any factors below 53 digits? If you mean to suggest that we wouldn't need to test primality on a factor if it's smaller than 106 digits, perhaps you should also discover how long a primality test is on a 90digit number, versus what work it would take to be sure there were no factors below 53 digits. Your observation, while utterly trivially true, allows someone to spend years of trial factoring to save milliseconds of a primality test. 
[QUOTE=Dr Sardonicus;467635]The clue I referred to in my post, was to the identity of the user kkmrkkblmbrbk[/QUOTE]
Yeah, that guy, he's a real weirdo. But he's not the discoverer of those factors, he just manually reported them to PrimeNet. The actual discoverer, whoever that is, only reported them to FactorDB. 
[QUOTE=Dr Sardonicus;467635]The clue I referred to in my post, was to the identity of the user kkmrkkblmbrbk[/QUOTE]
That is GP2's primenet id. He got the factor from factordb and reported it to mersenne.org. EDIT: Crossposted with GP2. 
[QUOTE=GP2;467638]Yeah, that guy, he's a real weirdo. But he's not the discoverer of those factors, he just manually reported them to PrimeNet. The actual discoverer, whoever that is, only reported them to FactorDB.[/QUOTE]So much for my vaunted skills at tracking things down or looking them up
:blush: I'll see if I can do better... 
[QUOTE=swellman;467939]That's the work of Ryan Propper. He's got most or all of the composite cofactors of M(3326400) < 1000 digits undergoing ECM. He's found a couple of factors in the big fdb list, as well as a couple from the list on the ElevenSmooth project page. Anything found from the list on the 11S page is reported here.
Ryan is also attempting the lowest difficulty SNFS composites as well, with factors reported here. There do not appear to be many feasible SNFS factorization jobs left in that project.[/QUOTE] Is this possibly the mysterious contributor who's added these factors to FDB? I've only barely skimmed both threads in question, but I believe this might be the culprit this thread is looking for. Edit: Nevermind, that was about composite Mersennes, which as far as I can tell have only small prime factors  not the largeish primes above 1000 as are in question here. 
[QUOTE=Dubslow;467981]Is this possibly the mysterious contributor who's added these factors to FDB? I've only barely skimmed both threads in question, but I believe this might be the culprit this thread is looking for.
Edit: Nevermind, that was about composite Mersennes, which as far as I can tell have only small prime factors  not the largeish primes above 1000 as are in question here.[/QUOTE] Actually, it is quite possible that it was indeed ryanp who did this. Clearly it was someone with a lot of resources, running deep ECM on multiple exponents. ryanp has been known to do lot of these over wide variety of candidates, including cunningham table stuff. These "low" prime exponent mersennes definitely qualifies. 
To those that have been running PRP tests on Mersenne cofactors:
Could you try submitting your PRP results to the primenet server? James has been upgrading the manual forms and I've been upgrading the database. Please let us know what does not work. 
Are there integrations between the two dbs so that results from one will flow into the other? Or should it be submitted to both?

I didn't know James was collecting the data. He just emailed me what he has. Once we get our act together, submitting results to Primenet will automatically be picked up by mersenne.ca.

Mersenne.ca's PRP data does not have the 64bit residue or user that ran the test. So, I still need those of you who ran PRP tests on Mersenne cofactors to submit the results using the manual web forms. It is OK to submit PRP results even if another factor was found at a later date.

I submitted the PRP data for M5641931 but I got the following error:
[code]Found 3 lines to process. processing: PRP=(false) for M5641931/11283863/180541793/217191775777/22553985486244307897/23294857194594233111 Error code: 11, error text: Update t_gimps_cofactor_PRP_results making M5641931 verified failed[/code] I performed tens of thousands of PRP tests, but after sending the results to James' database I deleted them, because Primenet did not accept these results. 
[QUOTE=alpertron;468093]I submitted the PRP data for M5641931 but I got the following error:
[code]Found 3 lines to process. processing: PRP=(false) for M5641931/11283863/180541793/217191775777/22553985486244307897/23294857194594233111 Error code: 11, error text: Update t_gimps_cofactor_PRP_results making M5641931 verified failed[/code][/QUOTE] I am getting the same error message. I still have most of my results.txt files, going back more than a year, including nearly all of the tests that were done for exponents larger than 4M. 
I added some PRP worktodo lines reserved from mersenne.ca into the worktodo file in a directory where UsePrimenet=1 is in effect.
As recently as a few days ago, upon completion the Primenet server would reject those results with an error message saying something like "unknown work type". Now it seems to accept the actual result, but then it says: [CODE] PrimeNet error 40: No assignment No CPU credit given for test of already factored M6600067 Done communicating with server [/CODE] This exponent was never reported before to either mersenne.ca or mersenne.org, and was only reserved by me at mersenne.ca a few hours earlier, so no one else worked on or reported this exponent either. Did the server accepting these automated submissions (for M6600067, M660053, and a couple of others pending, or will they need to be submitted through the manual form once that is debugged? 
[QUOTE=GP2;468100]
As recently as a few days ago, upon completion the Primenet server would reject those results with an error message saying something like "unknown work type". Now it seems to accept the actual result, but then it says: [CODE] PrimeNet error 40: No assignment No CPU credit given for test of already factored M6600067 Done communicating with server [/CODE] Did the server accepting these automated submissions (for M6600067, M660053, and a couple of others pending, or will they need to be submitted through the manual form once that is debugged?[/QUOTE] My apologies. I tested this stuff on the test server using prime95 version 29.4 which returns more information (PRP_base and number_of_known_factors). Without this information, the result is being treated as a PRP test using no known factors. Of course, since there are known factors, the server thinks these PRP tests are useless. Unless I can think of something clever, these results will have to be sent to the server using the manual web pages. 
[QUOTE=GP2;468094]I am getting the same error message.
I still have most of my results.txt files, going back more than a year, including nearly all of the tests that were done for exponents larger than 4M.[/QUOTE] How about emailing these to me and tell me what GIMPS userid you'd like them submitted under. 
[QUOTE=Prime95;468122]Unless I can think of something clever, these results will have to be sent to the server using the manual web pages.[/QUOTE]
The manual results page is still giving that error code 11, though. 
[QUOTE=GP2;468138]The manual results page is still giving that error code 11, though.[/QUOTE]
If you email your results, I'll start debugging the problem. 
[QUOTE=Prime95;468140]If you email your results, I'll start debugging the problem.[/QUOTE]
OK, I sent files to your alum address. Note the zip files were created on Linux, so the lines are LFterminated rather than CR LF. 
[QUOTE=Prime95;468122]My apologies. I tested this stuff on the test server using prime95 version 29.4 which returns more information (PRP_base and number_of_known_factors).[/QUOTE]
The results file always echos back the full list of known factors, so the parser should be able to infer how many there are. Sometimes they are listed on the same line, sometimes they are listed on a second line: Mnnnnnnn/fffffffff/fffffff/fffff is not prime Mnnnnnnn/known_factors is not prime Known factors used for PRP test were: fffffffff,fffffff,fffff How does the PRP base work? I always figured it uses a default and only does multiple bases when it thinks it's found a probable prime. 
PRP base is always 3 in your prime95 version.

I retested manually reporting (to Primenet) three PRP results, and it now produces:
processing: PRP=(false) for M6600071/3468205309081/52800569 Notice: Undefined index: residue_type in C:\inetpub\www\manual_result\manual_result.inc.php on line 377 Warning: odbc_do(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword 'AND'., SQL state 37000 in SQLExecDirect in C:\inetpub\v5\v5server\0.95_database.inc.php on line 145 Warning: odbc_do(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword 'AND'., SQL state 37000 in SQLExecDirect in C:\inetpub\v5\v5server\0.95_database.inc.php on line 145 Warning: odbc_do(): SQL error: [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert the value NULL into column 'PRP_result64_type', table 'primenet.dbo.t_gimps_cofactor_PRP_results'; column does not allow nulls. INSERT fails., SQL state 23000 in SQLExecDirect in C:\inetpub\v5\v5server\0.95_database.inc.php on line 286 Error code: 13, error text: Insert t_gimps_cofactor_PRP_results failed for M6600071 and similarly for processing: PRP=(false) for M6600101/1202020373472713 and processing: PRP=(false) for M6600107/52800857/646810487 Yet, these do show up in my Work Result Details ( [url]https://mersenne.org/results[/url] ) I hope the database is not in some inconsistent state. What is the way forward? Should we just wait for 29.4 ? I'm not worried about lost time, since it's always possible to fire up extra cloud instances later and get caught up. 
I made some changes to the PRP database yesterday, adding a column that identifies the residue type (gpuOwl and prime95 compute different residues).
This of course broke the manual forms. James will fix it soon enough. When he does just resubmit the results. Automated PRP testing using prime95 29.3 and earlier only partially works. All results should be resubmitted using the manual forms. 
[QUOTE=GP2;468410]Notice: Undefined index: residue_type in manual_result.inc.php on line 377[/QUOTE]Manual results form has been fixed, please try resubmitting.

[QUOTE=James Heinrich;468430]Manual results form has been fixed, please try resubmitting.[/QUOTE]
I'll try the form again with a new set of exponents, however for the three specific exponents in question, they can't be resubmitted: processing: PRP=(false) for M6600071/3468205309081/52800569 Error code: 40, error text: Another computer has already reported this PRP result for M6600071 processing: PRP=(false) for M6600101/1202020373472713 Error code: 40, error text: Another computer has already reported this PRP result for M6600101 processing: PRP=(false) for M6600107/52800857/646810487 Error code: 40, error text: Another computer has already reported this PRP result for M6600107 So please check the database for these three to make sure the null fields in the previous error messages are fixed up. 
[QUOTE=GP2;468435]
processing: PRP=(false) for M6600071/3468205309081/52800569 Error code: 40, error text: Another computer has already reported this PRP result for M6600071 processing: PRP=(false) for M6600101/1202020373472713 Error code: 40, error text: Another computer has already reported this PRP result for M6600101 processing: PRP=(false) for M6600107/52800857/646810487 Error code: 40, error text: Another computer has already reported this PRP result for M6600107.[/QUOTE] These 3 were properly added to the database 
I got the same error codes for the next set of exponents, although these were never reported before:
processing: PRP=(false) for M6600119/1320023801/1791760916609809 Error code: 40, error text: Another computer has already reported this PRP result for M6600119 processing: PRP=(false) for M6600133/243940915681 Error code: 40, error text: Another computer has already reported this PRP result for M6600133 processing: PRP=(false) for M6600157/7993318139561 Error code: 40, error text: Another computer has already reported this PRP result for M6600157 
Those are in the database  reported by you.
Are you having mprime report these results to the server? If so, PRP tests with few factors are getting properly recorded (the ones that have the result split across 2 lines are not recorded properly). 
[QUOTE=GP2;467589]Also, anyone that contributes to these forums would surely manually report any new finds to PrimeNet, which our mystery person is not doing.[/QUOTE]
OK. I know how to report a result from prime95. And I know how to report a result from mfactc. But, a brief search did not reveal the trivially simple manual report form, to report a factor, when I know nothing about the method used for factorization and I do not want credit for a find that isn't mine? If there is no obvious way to report, then don't expect a report. 7051863324605499849483215166120814618029888281331456062662199692938569 
[QUOTE=rcv;468471]If there is no obvious way to report, then don't expect a report.
7051863324605499849483215166120814618029888281331456062662199692938569[/QUOTE] I added it as anonymous: [url]http://mersenne.org/M1549[/url] Just log out of mersenne.org if you do not want the credit and then "Manuel Testing"  "Results" and paste in: [B]M1549 has a factor: 7051863324605499849483215166120814618029888281331456062662199692938569[/B] 
[QUOTE=Prime95;468464]Those are in the database  reported by you.
Are you having mprime report these results to the server? If so, PRP tests with few factors are getting properly recorded (the ones that have the result split across 2 lines are not recorded properly).[/QUOTE] No, those just were pasted into the [URL="https://mersenne.org/manual_result/"]Manual Results[/URL] form. So it's recording the oneline results correctly, even though it returns a bogus error code 40? OK, I guess I could preselect only exponents that have a short list of factors, which will generate only oneline results, unless it's better just to wait for 29.4. 
[QUOTE=ATH;468472]I added it as anonymous: [url]http://mersenne.org/M1549[/url][/QUOTE]
Maybe [M]1471[/M] and [M]1489[/M] could be changed to Anonymous too in the database, it didn't occur to me that you could report them that way. No need to adjust the credit, since they received 0.0000 due to the assumption of an absurdly low B1. 
[QUOTE=GP2;468479]No, those just were pasted into the [URL="https://mersenne.org/manual_result/"]Manual Results[/URL] form.
So it's recording the oneline results correctly, even though it returns a bogus error code 40? OK, I guess I could preselect only exponents that have a short list of factors, which will generate only oneline results, unless it's better just to wait for 29.4.[/QUOTE] The manual results web page handles both the one and two line results. 
[QUOTE=Prime95;468464]Are you having mprime report these results to the server? If so, PRP tests with few factors are getting properly recorded (the ones that have the result split across 2 lines are not recorded properly).[/QUOTE]
[QUOTE=Prime95;468486]The manual results web page handles both the one and two line results.[/QUOTE] So, this form: [B]Mnnnnnnn/fffffffff/fffffff/fffff is not prime[/B] can be either reported automatically or manually. Whereas the form [B]Mnnnnnnn/known_factors is not prime[/B] [B]Known factors used for PRP test were: fffffffff,fffffff,ffffffffffffffffffffffffff[/B] can only be reported manually. Empirically, it turns out that the criterion for mprime using one form or the other is not the number of factors, but the total length of the factor string (including commas, if any). If the length is 40 or more, then mprime will report the result using the twoline "known factors" form. For example, in the following worktodo line: PRP=N/A,1,2,6166471,1,"1039038030559,51421412360713,61664711" the part between double quotes has length 37, so mprime will report it using the simple oneline form. So you can segregate all the lines with long (40+) factor strings into a separate work directory that has UsePrimenet=0 in the prime.txt file, and leave all the rest in the main work directory that has UsePrimenet=1. Typically, in the 6M range where the firsttime PRP wavefront is at, less than 10 percent of the exponents have long (length = 40+) factor strings, so only that small fraction of results needs to be manually reported. 
[QUOTE=GP2;468692]Empirically, it turns out that the criterion for mprime using one form or the other is not the number of factors, but the total length of the factor string (including commas, if any). If the length is 40 or more, then mprime will report the result using the twoline "known factors" form.[/QUOTE]
So, the server could be modified already to automatic assign exponents to workers requesting PRP work type, as long as a temporary restriction was put in place, to assign an exponent only if its factor string has length less than 40. 
mersenne.ca PRP sometimes generates incomplete factor strings
When getting PRP assignments from mersenne.ca, the PRP= lines generated for the worktodo file sometimes have missing factors. This is fairly rare, but does happen.
As I mentioned earlier, I am now doing automated reporting of PRP results to mersenne.org, after first filtering out any exponents with factor strings of length 40 or more (which produce the twoline "known_factors" output that requires manual results reporting). In my prime.log files, I found the following lines: No CPU credit given for test of already factored M6187451 No CPU credit given for test of already factored M6176983 No CPU credit given for test of already factored M6177151 No CPU credit given for test of already factored M6168247 In my results.txt files, I found: M6187451/497483435303/51974588401 is not prime. M6176983/12069824783/395326913 is not prime. M6177151/149279563697911 is not prime. M6168247/80187211001 is not prime. In each case, there is a factor missing. [M]M6187451[/M] has three factors, the other one is 16042392306210401 (discovered 20141015) [M]M6176983[/M] has three factors, the other one is 23418769077829996889 (discovered 20170914) [M]M6177151[/M] has two factors, the other one is 10702995701931497 (discovered 20140912) [M]M6168247[/M] has two factors, the other one is 19799494695535703 (discovered 20141105) I was using PRP= lines assigned through mersenne.ca, so it must have been mersenne.ca that generated those lines with missing factors. The factor discovered 20170914 is understandable, most likely it was discovered after I got the assignment but before I returned the result. However the cases involving factors from 2014 are harder to explain. If you go to [url]http://www.mersenne.ca/exponent/6187451[/url] it shows all three factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6187451&max_exponent=6187451"]PRP data[/URL] shows only two factors. If you go to [url]http://www.mersenne.ca/exponent/6177151[/url] it shows both factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6177151&max_exponent=6177151"]PRP data[/URL] shows only one factor. If you go to [url]http://www.mersenne.ca/exponent/6168247[/url] it shows both factors, but the [URL="http://www.mersenne.ca/prp.php?show=2&min_exponent=6168247&max_exponent=6168247"]PRP data[/URL] shows only one factor. This would appear to confirm that the list of known factors maintained by the PRP subsection of mersenne.ca is not always in sync with the main list of known factors, and therefore the PRP= lines generated are sometimes missing factors. Any PRP test done with missing factors is not useful. Fortunately, this situation seems to be fairly rare, maybe one to two percent of the exponents in the 6.1M range, based on a small sample size (three cases out of about 200 so far, not counting M6176983 because its additional factor was very recently discovered). This might be a longstanding problem, so it is possible that the coverage for exponents below 6.1M might not be as complete as [URL="http://www.mersenne.ca/prp.php?assigned_distribution=1"]the table[/URL] would indicate. 
[QUOTE=GP2;468800]When getting PRP assignments from mersenne.ca, the PRP= lines generated for the worktodo file sometimes have missing factors. This is fairly rare, but does happen... Fortunately, this situation seems to be fairly rare, maybe one to two percent of the exponents in the 6.1M range... This might be a longstanding problem, so it is possible that the coverage for exponents below 6.1M might not be as complete as [URL="http://www.mersenne.ca/prp.php?assigned_distribution=1"]the table[/URL] would indicate.[/QUOTE]Thank you for discovering and reporting this.
The PRP table is supposed to be updated when new factors are reported, but clearly there was a problem around Q42014 because I found quite a few exponents with mismatches between the PRP list cofactors and the master list of known factors. I didn't count them exactly, but it looks like around 1% as you said, which means as I write this there are now nearly 3000 new small PRP assignments (up to the 6M wavefront). This shouldn't be an ongoing problem, but to be safe I've added a check to the nightly cronjob to check for missing known factors and reset the PRP list as appropriate. 
I submitted 240 results for the first million range, but after accepting the results, I see them again as available.

[QUOTE=alpertron;468837]I submitted 240 results for the first million range, but after accepting the results, I see them again as available.[/QUOTE]My fault, fixed now. I also resubmitted your results and they've been accepted (properly this time).

It is working now. Thanks.

Can we clarify what prevents parsing of twoline PRP output?
For example: UID: user/machine, M6170251/known_factors is not prime. RES64: E361D74562C55F__. Wf8: DD047E1F,00000000 Known factors used for PRP test were: 1008607048144889,15751823989367,3167226859807 The first line provides the exponent and residue. The second line provides the factors, but not the exponent. However, we can easily determine the exponent with a single extra SQL query. Mersenne numbers with prime exponents can never share the same factor. So just copy the factor string verbatim into your SQL statement, something like: select distinct exponent from factors_table where factor in ( 1008607048144889,15751823989367,3167226859807 ) which is mathematically guaranteed to return exactly one row. So parse the first line to create a row and populate some of the columns, then use the second line to update the row and populate the remaining columns. Would that work? 
The problem is that prime95 is not sending the second line of text to the server  it is only written to the screen and results.txt file.

Twoline output is correctly parsed by the manual results form, it's only the automatic clientserver communication that has the problem.

I submitted to Primenet the PRP results for M611999 (cofactor probable prime, as listed in [URL="http://www.primenumbers.net/prptop/searchform.php?form=%282%5En1%29%2F%3F&action=Search"]Henri and Renauld Lifchitz's PRP Top Records[/URL]), and the results page shows:
[CODE] Found 3 lines to process. processing: PRP=(true) for M611999/18464214225958267477777390354183 Error code: 40, error text: No CPU credit given for test of already factored M611999 Done processing: * Parsed 2 lines. * Found 1 datestamps. GHzdays Qty Work Submitted Accepted Average 1 PRP (Probable Prime): PRIME 0.009  0.009 1  all  0.009 [/CODE] The [URL="https://www.mersenne.org/report_exponent/?exp_lo=611999&exp_hi=&full=1&ecmhist=1"]exponent status for M611999[/URL] does not show that the cofactor is probable prime. 
[QUOTE=alpertron;468957]The [URL="https://www.mersenne.org/report_exponent/?exp_lo=611999&exp_hi=&full=1&ecmhist=1"]exponent status for M611999[/URL] does not show that the cofactor is probable prime.[/QUOTE]
In case anyone reading this is confused, that's [URL="http://mersenneforum.org/showpost.php?p=460879&postcount=308"]an old PRP[/URL]. mersenne.org is showing PRP test residues (in the History section) if that residue is nonzero, but does not yet show that an exponent is fully factored or probablyfullyfactored. They're slowly working on adding PRPrelated functionality to the website and I guess that's one thing they just haven't gotten around to yet. PS, Note that [URL="http://factordb.com/index.php?id=1100000000936638975"]FactorDB does not show that the cofactor is prime[/URL], for this or any other PRPcofactor of Mersenne exponents above 500 000, and there doesn't seem to be any way to report its PRPness to FactorDB. 
The 317th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M8243[/M].
Congratulations to Yaroslav Berezhko, who discovered the a new 42digit factor using ECM and promptly ran the PRP test. It's easy to do a double check, it takes a matter of seconds. The double check uses the same shift count of zero with v 29.3, but I think we can trust it. Is anyone doing the primality certificate? PS, Looks like the email alert system is working fine. PPS, The residue of the cofactor is PRP_PRP_PRP_PR__. Those are some strange hexadecimal digits. 
[QUOTE=GP2;469568]The 317th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M8243[/M].
Congratulations to Yaroslav Berezhko, who discovered the a new 42digit factor using ECM and promptly ran the PRP test. It's easy to do a double check, it takes a matter of seconds. The double check uses the same shift count of zero with v 29.3, but I think we can trust it. Is anyone doing the primality certificate? PS, Looks like the email alert system is working fine. PPS, The residue of the cofactor is PRP_PRP_PRP_PR__. Those are some strange hexadecimal digits.[/QUOTE] I am too busy to do the certification. It should take someone else minutes. Edit: I am on it. 
4 Attachment(s)
Hmmm, nearly all of the known (probably)fullyfactored exponents don't have any indication of their status at Mersenne.org, except for [M]M4834891[/M].
For example, [M]M7331[/M] or [M]M10211[/M]. George, if you're reading this, one of the files I emailed you a few weeks ago was called verification_results.txt, which was a double check of all the known exponents (at the time I ran it, which was probably before the last few discoveries). Attached below is a file with just the list of exponents. Also, a file with worktodo lines, for anyone who wants to do a full double check of the entire list just for fun. [B]Note:[/B] Use the _CRLF versions if you're using Windows, otherwise the lines won't look right. The other versions are for Linux. The double check of the complete list should only take a few hours, most of which will be spent on the last few larger exponents. Of course, all of these have already been doublechecked, although a proper doublecheck should later be done with different shift counts, with v 29.4 Note that all exponents in the list up to and including [M]M63703[/M] have been verified fullyfactored by primality certificate. The others are only (very) probablyfullyfactored. The Primenet database should probably distinguish between the two cases, as Mersenne.ca already does. The certificates are available at FactorDB.com. The difficulty of generating a primality certificate rises steeply, perhaps even proportional to the fourth power of the exponent if I recall, so the next higher known exponents, in the 80k range, would take months to do. So we will always have this distinction between proven fullyfactored and probably fullyfactored. 
[url]http://www.factordb.com/index.php?id=1100000001051589997[/url]
M8243cofactor certificate. :smile: Congrats to Yaroslav Berezhko. 
Mersenne.org is now listing PRP residues in a separate Cofactor PRP section. Excellent.
However, all old residues should be deleted from this section whenever a new factor is discovered. They can still be found in the History, although they are no longer useful. See for instance [M]M209233[/M], or indeed the newly fully factored [M]M8243[/M]. 
[QUOTE=GP2;469571]The others are only (very) probablyfullyfactored. The Primenet database should probably distinguish between the two cases, as Mersenne.ca already does.[/QUOTE]
The database does distinguish but needs to be updated manually as the server does not store certificates. 
2 Attachment(s)
Sorry if this is offtopice, but I wanted to try PRIMO as I've never used it before.
I tried it on a (SandyBridge based) 1x Xeon 2620 (6c12t, 2GHzish) with 16GB ECC RAM and Ubuntu 16.04 LTS I used 12 threads and sieve 5000  25 bits (is there a guide on what parameters to use? I couldn't find it in the readme or FAQ?) So I tried some of the standard input files and added M8243cofactor as an exercise 10^55+21  0.13s 10^700+7  12.57s 10^999+7  61s M8243cofactor  1826s They were all prime (as known/expected) and I got a bunch of files now :confused2: .in (the Input, that makes sense) .wr (Work Report?) .cr (Certificate Report?) .out (Primality Certificate?) So which ones do you need to upload/report in case it is a new test and where do you upload them? 
[QUOTE=VictordeHolland;469589]Sorry if this is offtopice, but I wanted to try PRIMO as I've never used it before.
I tried it on a (SandyBridge based) 1x Xeon 2620 (6c12t, 2GHzish) with 16GB ECC RAM and Ubuntu 16.04 LTS I used 12 threads and sieve 5000  25 bits (is there a guide on what parameters to use? I couldn't find it in the readme or FAQ?) So I tried some of the standard input files and added M8243cofactor as an exercise 10^55+21  0.13s 10^700+7  12.57s 10^999+7  61s M8243cofactor  1826s They were all prime (as known/expected) and I got a bunch of files now :confused2: .in (the Input, that makes sense) .wr (Work Report?) .cr (Certificate Report?) .out (Primality Certificate?) So which ones do you need to upload/report in case it is a new test and where do you upload them?[/QUOTE] My test of M8243cofactor took 1400 seconds on a o/c 4770k. I uploaded the certificate  yes the .out file  to [url]http://www.factordb.com/result.php[/url]. I used the default parameters, but on big jobs I max them out. 
[QUOTE=paulunderwood;469591]My test of M8243cofactor took 1400 seconds on a o/c 4770k. I uploaded the certificate  yes the .out file  to [URL]http://www.factordb.com/result.php[/URL].
I used the default parameters, but on big jobs I max them out.[/QUOTE] Thx! Yeah, my time seems to be what is expected, considering it is 2 generations older and the GHz*cores is lower than yours. Xeon 2620 (6c*2.3GHz=13.8) vs. your 4770k (4c*4GHz??=16?). 
[QUOTE=GP2;469584]Mersenne.org is now listing PRP residues in a separate Cofactor PRP section. Excellent.[/QUOTE]Mersenne.ca now automatically imports PRP results from mersenne.org (overnightly), and the exponent details page has an additional section with the PRP logs from PrimeNet.

The 318th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M20521[/M].
I found the most recent factor, and Oliver Kruse did the PRP test. As usual, needs a Primo certificate, if anyone wants to do it. As is usually the case for small exponents, the ECM curve that found the factor actually output "Cofactor is a probable prime", although I didn't notice this until after the fact. So the ECM code automatically does a PRP test, at least for small exponents, and calculates a residue. Perhaps in future versions it could send that residue result straight to the database. 
[QUOTE=GP2;470064]The 318th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M20521[/M].
I found the most recent factor, and Oliver Kruse did the PRP test. As usual, needs a Primo certificate, if anyone wants to do it.[/QUOTE] I'm certifying it now... :cool: 
[URL="http://www.factordb.com/index.php?id=1100000001055837715"]Certification of the M20521 cofactor[/URL] is complete. This [URL="http://primes.utm.edu/primes/page.php?id=123954"]prime[/URL] makes it into the [URL="http://primes.utm.edu/top20/page.php?id=49"]top20[/URL] Mersenne cofactors. :thumbsup:

I notice something amusing WRT fullyfactored Mp's whose last factor is a PRPcumcertifiedprime: The tables, e.g.for [url=http://www.mersenne.ca/exponent/20521]20521[/url] or even [url=http://www.mersenne.ca/exponent/397]397[/url] list all but the last factor as "known prime factors" but describe the remaining cofactor as a "certifiedprime." In the case of 397, this affects the description in the table of [url=http://www.mersenne.ca/manyfactors.php]Top Mersenne exponents with the most known factors[/url], which says M397 has only 8 known prime factors! Since the last factor is only 31 decimal digits, the primality would seem to beyond cavil...

[QUOTE=Dr Sardonicus;470106]I notice something amusing WRT fullyfactored Mp's whose last factor is a PRPcumcertifiedprime: The tables, e.g.for [url=http://www.mersenne.ca/exponent/20521]20521[/url] or even [url=http://www.mersenne.ca/exponent/397]397[/url] list all but the last factor as "known prime factors" but describe the remaining cofactor as a "certifiedprime." In the case of 397, this affects the description in the table of [url=http://www.mersenne.ca/manyfactors.php]Top Mersenne exponents with the most known factors[/url], which says M397 has only 8 known prime factors! Since the last factor is only 31 decimal digits, the primality would seem to beyond cavil...[/QUOTE]
And [M]M11[/M] has only "one" known factor, even though it's actually the product of 23 × 89. For the sake of consistency we always omit that final cofactor, which is usually both enormous and composite. 
[QUOTE=Dr Sardonicus;470106]In the case of 397, this affects the description in the table of [url=http://www.mersenne.ca/manyfactors.php]Top Mersenne exponents with the most known factors[/url], which says M397 has only 8 known prime factors! Since the last factor is only 31 decimal digits, the primality would seem to beyond cavil...[/QUOTE]There are indeed 9 factors for M397, the smallest 8 of which are listed on the [url=http://www.mersenne.ca/exponent/397]exponent page[/url], the last one (6597485910270326519900042655193) is only shown on demand on the [url=http://www.mersenne.ca/prp.php?show=2&min_exponent=0&max_exponent=1000#M397]PRP page[/url].
I have updated the [url=http://www.mersenne.ca/manyfactors.php]manyfactors page[/url] to take these kind of PRP lastfactors into account, the affected exponents are shown in red. And yes, in many cases with smaller exponents the percentageknown won't quite reach 100% due to rounding. 
[QUOTE=James Heinrich;470125]There are indeed 9 factors for M397, the smallest 8 of which are listed on the [url=http://www.mersenne.ca/exponent/397]exponent page[/url], the last one (6597485910270326519900042655193) is only shown on demand on the [url=http://www.mersenne.ca/prp.php?show=2&min_exponent=0&max_exponent=1000#M397]PRP page[/url].
I have updated the [url=http://www.mersenne.ca/manyfactors.php]manyfactors page[/url] to take these kind of PRP lastfactors into account, the affected exponents are shown in red. And yes, in many cases with smaller exponents the percentageknown won't quite reach 100% due to rounding.[/QUOTE]Thanks, the PRP page clearly lists the cases when 2^n  1 is either fully factored, or the remaining cofactor has been tested as a PRP, but not known to be prime. The old printed tables usually list the last cofactor as Pxxx, PRPxxx, or Cxxx (proven prime, tested as PRP, or proven composite (i.e. tested as notPRP) with xxx decimal digits). The only additional notation I can think of offhand is Uxxx, ("unknown" or "untested," for any cases where the remaining cofactor has not been PRPtested. 
The [STRIKE]318th[/STRIKE] 319th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M7080247[/M].
This is a new record for Mersenne PRPs, the previous record was [M]M5240707[/M]. 
[QUOTE=GP2;470443]The 318th fullyfactored or probablyfullyfactored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M7080247[/M].
[/QUOTE] Congrats! Submitted under your name to [URL="http://www.primenumbers.net/prptop/prptop.php"]PRP top[/URL] 
All times are UTC. The time now is 13:39. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2022, Jelsoft Enterprises Ltd.