mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Data (https://www.mersenneforum.org/forumdisplay.php?f=21)
-   -   Mersenne number factored (disbelievers are biting elbows) (https://www.mersenneforum.org/showthread.php?t=19407)

Gordon 2017-03-10 14:05

[QUOTE=Batalov;454579]The proverbial disbelievers, right? :rolleyes:[/QUOTE]

...and it wasn't me :leaving:

GP2 2017-04-05 11:30

[M]M12569[/M] is the 313th known fully-factored or probably-fully-factored Mersenne number.

Anyone want to run Primo on it?

paulunderwood 2017-04-05 13:41

[QUOTE=GP2;456219][M]M12569[/M] is the 313th known fully-factored or probably-fully-factored Mersenne number.

Anyone want to run Primo on it?[/QUOTE]

:jcrombie: I will do it

paulunderwood 2017-04-05 16:36

[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:

alpertron 2017-06-02 18:20

[URL="https://www.mersenne.ca/exponent/174533"]M174533[/URL] is the 314th known Mersenne number probably fully factored.

ewmayer 2017-06-03 03:42

Been a long time since I fiddled with the M-cofactors, 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 greedy-for-credit, but a link to the aforementioned mailing-list posting might be in order for the References section. I will fwd link to this post to Chris C. after it goes up.

paulunderwood 2017-06-03 05:07

[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 M174533-cofactor 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]

GP2 2017-06-03 13:27

[QUOTE=ewmayer;460386]Not to seem greedy-for-credit, but a link to the aforementioned mailing-list 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 proven-prime cofactors, so his list tops out at M63703 even though the record probable-prime 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.

Batalov 2017-06-03 18:14

[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 32-core 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,600-digit number (~8 times more core time) is doable this way without too much trouble.

In 1997, of course, this was not feasible or cheap.

paulunderwood 2017-06-03 18:54

[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:

alpertron 2017-06-03 21:14

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.

ewmayer 2017-06-03 21:38

[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 general-prime proving with the ECPP proof of the M7331 cofactor, and that required several months-long 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.

GP2 2017-06-03 21:42

[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.

GP2 2017-06-07 03:53

[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
------------------------------------------------------------
1K-2K 45 14 17 20
2K-5K 26 17 20 24
5K-10K 16 12 14 16
10K-20K 10 11 13 15
20K-50K 8 13 16 18
50K-100K 7 9 11 13
100K-200K 5 9 10 12
200K-500K 5 11 13 15
500K-1M 3 8 9 11
1M-2M 3 7 9 10
2M-3M 0 4 5 6
3M-4M 0 3 3 4
4M-5M 0 2 3 3
5M-10M 0 7 8 9
[/CODE][/QUOTE]

The above was posted in August 2014.

It represents a prediction, made at the time, about the second-largest factor of fully-factored (or probably-fully-factored) 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 FF-or-PFF exponents in a given range whose second-largest 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 FF-or-PFF 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".

axn 2017-06-07 11:03

[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).

GP2 2017-06-07 18:04

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
4M-5M 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]
26-30 digits: [M]1307[/M]
31-35 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]
26-30 digits: [M]2251[/M] [M]2447[/M] [M]2909[/M] [M]3079[/M]
31-35 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]
26-30 digits: [M]6043[/M]
31-35 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]
26-30 digits: [M]17683[/M] [M]19121[/M]
31-35 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]
26-30 digits: [M]25243[/M] [M]35339[/M] [M]41521[/M]
31-35 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]
26-30 digits: [M]84211[/M] [M]86137[/M]
31-35 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]
26-30 digits or less: [M]174533[/M]
31-35 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]

alpertron 2017-06-09 17:18

The 315th in the list is: [URL="http://www.mersenne.ca/exponent/611999"]M611999 = 18464214225958267477777390354183 * PRP184199[/URL]

paulunderwood 2017-06-09 17:34

[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 M611999-cofactor 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]

axn 2017-09-03 11:14

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

GP2 2017-09-03 13:16

[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 GHz-days."

If the actual discoverer is a GIMPS user, maybe the database can be adjusted.

GP2 2017-09-11 18:08

[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 295-digit 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.

xilman 2017-09-11 18:54

[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?

GP2 2017-09-11 19:34

[QUOTE=xilman;467563]Have you tried contacting SSW?[/QUOTE]

No, but these exponents are a tad larger than the Cunningham project limit.

Dr Sardonicus 2017-09-11 21:26

[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 295-digit 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]2017-09-11 kkmrkkblmbrbk F-ECM Factor: 95909518295775374166321292697000685895150503357477127[/quote]

Post #38 on page 4 of the thread [url=http://www.mersenneforum.org/showthread.php?t=21115&page=4]P-1 factoring attempts at smallest-remaining Mersenne numbers with no known factors[/url] might give a clue.

GP2 2017-09-11 23:54

[QUOTE=Dr Sardonicus;467581]Post #38 on page 4 of the thread [url=http://www.mersenneforum.org/showthread.php?t=21115&page=4]P-1 factoring attempts at smallest-remaining 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.

VBCurtis 2017-09-12 00:36

[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 GNFS-295 on the remaining cofactor, or SNFS on the original 1489-bit number.

Both would be world records.

GP2 2017-09-12 00:45

[QUOTE=VBCurtis;467592]How do you figure? You said the cofactor is 295 digits, right? So this is either GNFS-295 on the remaining cofactor, or SNFS on the original 1489-bit 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.

science_man_88 2017-09-12 01:09

[QUOTE=VBCurtis;467592]How do you figure? You said the cofactor is 295 digits, right? So this is either GNFS-295 on the remaining cofactor, or SNFS on the original 1489-bit 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.

VBCurtis 2017-09-12 05:51

[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 run-on. 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.

xilman 2017-09-12 06:17

[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. base-3 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.

retina 2017-09-12 06:21

[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?

science_man_88 2017-09-12 10:17

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).

rcv 2017-09-12 12:06

[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^n-1 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 near-Cunningham numbers. Maybe the two Mersenne numbers were just a coincidence. ryanp acknowledges factoring a couple of these in the ElevenSmooth thread.

Dr Sardonicus 2017-09-12 15:39

[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

VBCurtis 2017-09-12 15:41

[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 2n-1 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 90-digit 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.

GP2 2017-09-12 15:56

[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.

axn 2017-09-12 15:58

[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:- Cross-posted with GP2.

Dr Sardonicus 2017-09-12 20:38

[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...

Dubslow 2017-09-17 23:22

[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 large-ish primes above 1000 as are in question here.

axn 2017-09-18 04:10

[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 large-ish 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.

Prime95 2017-09-19 03:52

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.

axn 2017-09-19 04:48

Are there integrations between the two dbs so that results from one will flow into the other? Or should it be submitted to both?

Prime95 2017-09-19 12:47

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.

Prime95 2017-09-19 12:57

Mersenne.ca's PRP data does not have the 64-bit 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.

alpertron 2017-09-19 13:40

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.

GP2 2017-09-19 13:52

[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.

GP2 2017-09-19 14:42

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?

Prime95 2017-09-19 21:07

[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.

Prime95 2017-09-19 21:10

[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.

GP2 2017-09-19 23:29

[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.

Prime95 2017-09-19 23:50

[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.

GP2 2017-09-20 02:31

[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 LF-terminated rather than CR LF.

GP2 2017-09-20 02:41

[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.

Prime95 2017-09-20 06:18

PRP base is always 3 in your prime95 version.

GP2 2017-09-23 07:09

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.

Prime95 2017-09-23 14:20

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.

James Heinrich 2017-09-23 15:16

[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.

GP2 2017-09-23 16:49

[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.

Prime95 2017-09-23 19:18

[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

GP2 2017-09-23 23:49

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

Prime95 2017-09-24 00:29

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).

rcv 2017-09-24 04:09

[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

ATH 2017-09-24 04:38

[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]

GP2 2017-09-24 11:10

[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 one-line results correctly, even though it returns a bogus error code 40? OK, I guess I could pre-select only exponents that have a short list of factors, which will generate only one-line results, unless it's better just to wait for 29.4.

GP2 2017-09-24 11:13

[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.

Prime95 2017-09-24 15:01

[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 one-line results correctly, even though it returns a bogus error code 40? OK, I guess I could pre-select only exponents that have a short list of factors, which will generate only one-line 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.

GP2 2017-09-28 01:23

[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 two-line "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 one-line 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 first-time 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.

GP2 2017-09-28 01:27

[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 two-line "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.

GP2 2017-09-29 07:57

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 two-line "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 2014-10-15)
[M]M6176983[/M] has three factors, the other one is 23418769077829996889 (discovered 2017-09-14)
[M]M6177151[/M] has two factors, the other one is 10702995701931497 (discovered 2014-09-12)
[M]M6168247[/M] has two factors, the other one is 19799494695535703 (discovered 2014-11-05)

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 2017-09-14 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 sub-section 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.

James Heinrich 2017-09-29 16:24

[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 Q4-2014 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.

alpertron 2017-09-29 19:01

I submitted 240 results for the first million range, but after accepting the results, I see them again as available.

James Heinrich 2017-09-29 19:33

[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).

alpertron 2017-09-29 20:14

It is working now. Thanks.

GP2 2017-09-30 18:03

Can we clarify what prevents parsing of two-line 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?

Prime95 2017-09-30 18:35

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.

James Heinrich 2017-09-30 19:16

Two-line output is correctly parsed by the manual results form, it's only the automatic client-server communication that has the problem.

alpertron 2017-10-01 13:59

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%5En-1%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.
GHz-days
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.

GP2 2017-10-01 15:26

[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 non-zero, but does not yet show that an exponent is fully factored or probably-fully-factored.

They're slowly working on adding PRP-related 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 PRP-cofactor of Mersenne exponents above 500 000, and there doesn't seem to be any way to report its PRP-ness to FactorDB.

GP2 2017-10-10 14:09

The 317th fully-factored or probably-fully-factored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M8243[/M].

Congratulations to Yaroslav Berezhko, who discovered the a new 42-digit 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 e-mail alert system is working fine.

PPS,
The residue of the cofactor is PRP_PRP_PRP_PR__. Those are some strange hexadecimal digits.

paulunderwood 2017-10-10 14:26

[QUOTE=GP2;469568]The 317th fully-factored or probably-fully-factored Mersenne number with prime exponent (not including the Mersenne primes themselves) is [M]M8243[/M].

Congratulations to Yaroslav Berezhko, who discovered the a new 42-digit 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 e-mail 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.

GP2 2017-10-10 14:27

4 Attachment(s)
Hmmm, nearly all of the known (probably-)fully-factored 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 e-mailed 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 double-checked, although a proper double-check 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 fully-factored by primality certificate. The others are only (very) probably-fully-factored. 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 fully-factored and probably fully-factored.

paulunderwood 2017-10-10 15:13

[url]http://www.factordb.com/index.php?id=1100000001051589997[/url]

M8243-cofactor certificate. :smile:

Congrats to Yaroslav Berezhko.

GP2 2017-10-10 16:42

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].

Prime95 2017-10-10 17:58

[QUOTE=GP2;469571]The others are only (very) probably-fully-factored. 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.

VictordeHolland 2017-10-10 19:09

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 (Sandy-Bridge based) 1x Xeon 2620 (6c12t, 2GHz-ish) 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
M8243-cofactor - 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?

paulunderwood 2017-10-10 19:30

[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 (Sandy-Bridge based) 1x Xeon 2620 (6c12t, 2GHz-ish) 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
M8243-cofactor - 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 M8243-cofactor 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.

VictordeHolland 2017-10-10 20:17

[QUOTE=paulunderwood;469591]My test of M8243-cofactor 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?).

James Heinrich 2017-10-10 22:18

[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.

GP2 2017-10-18 12:17

The 318th fully-factored or probably-fully-factored 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.

paulunderwood 2017-10-18 12:40

[QUOTE=GP2;470064]The 318th fully-factored or probably-fully-factored 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:

paulunderwood 2017-10-19 10:33

[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. :thumbs-up:

Dr Sardonicus 2017-10-19 14:05

I notice something amusing WRT fully-factored Mp's whose last factor is a PRP-cum-certified-prime: 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 "certified-prime." 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...

GP2 2017-10-19 18:45

[QUOTE=Dr Sardonicus;470106]I notice something amusing WRT fully-factored Mp's whose last factor is a PRP-cum-certified-prime: 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 "certified-prime." 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.

James Heinrich 2017-10-19 22:49

[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]many-factors page[/url] to take these kind of PRP last-factors into account, the affected exponents are shown in red.
And yes, in many cases with smaller exponents the percentage-known won't quite reach 100% due to rounding.

Dr Sardonicus 2017-10-20 15:07

[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]many-factors page[/url] to take these kind of PRP last-factors into account, the affected exponents are shown in red.
And yes, in many cases with smaller exponents the percentage-known 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 not-PRP) 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 PRP-tested.

GP2 2017-10-27 08:33

The [STRIKE]318th[/STRIKE] 319th fully-factored or probably-fully-factored 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].

Batalov 2017-10-27 14:37

[QUOTE=GP2;470443]The 318th fully-factored or probably-fully-factored 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.