P-1 found a factor in stage #1, B1=729000.
UID: Jwb52z/Clay, M101165227 has a factor: 191612436557663486778337 (P-1, B1=729000)

77.343 bits.

Found a 74 bit factor for [M]122223323[/M], not a big factor, but a nice looking number.

UID: nordi/sweet16, M1489 has a factor: 430768120877571983358263339450368443038134995818878229278591 (ECM curve 4082, B1=1000000000, B2=19071176724616)


60 digit factor, and what's left is a probable prime! Santa came rather early this year ;-)

[QUOTE=nordi;566410][M]M1489[/M] has a 198.101-bit (60-digit) factor: [url=https://www.mersenne.ca/M1489]430768120877571983358263339450368443038134995818878229278591[/url] (ECM,B1=1000000000,B2=19071176724616)[/QUOTE]Wow! Congrats! :party:

:clap:

[QUOTE=nordi;566410]UID: nordi/sweet16, M1489 has a factor: 430768120877571983358263339450368443038134995818878229278591 (ECM curve 4082, B1=1000000000, B2=19071176724616)


60 digit factor, and what's left is a probable prime! Santa came rather early this year ;-)[/QUOTE]

nice!

[QUOTE=nordi;566410]M1489 has a <snip> 60 digit factor, and what's left is a <snip> prime![/QUOTE]
Yeaaaa! B-E-A-utiful!
We wish you more like that!
:chappy:

[M]M32140793[/M] has a 101.170-bit (31-digit) factor: [url=https://www.mersenne.ca/M32140793]2852080042007189358945866948633[/url] (P-1,B1=600000,B2=13000000,E=12)

Lucky hit
 

Yesterday my GPU found this pair of factors:

13648334340553940219999 = 2 * 52,571,576,271,773 * [I][M]129807163[/M][/I] + 1
13688346971328393811703 = 2 * 52,725,699,626,177 * [I][M]129807163[/M][/I] + 1

Interesting how close they are in the 73-bit range.

[M]M32149987[/M] has a 104.328-bit (32-digit) factor: [url=https://www.mersenne.ca/M32149987]25465534989790678974932725022593[/url] (P-1,B1=1000000,B2=20000000,E=12)
Thats my new record.

Slowing inching toward top 500 (117.xx bits)

[M]M101736851[/M] has a 76.139-bit (23-digit) factor: [URL="https://www.mersenne.ca/M101736851"]83187494794024727844737[/URL] (P-1,B1=650000)

Nowhere near my record length, but what the heck. :smile:

[M]M19322383[/M] has a 114.614-bit (35-digit) factor: [url=https://www.mersenne.ca/M19322383]31779137418604066217200202610865553[/url] (P-1,B1=401000,B2=401000)

Biggest P-1 factor of the [url=https://www.mersenne.ca/userfactors/pm1/recent/bits]past 7 days[/url].
Also, should have been found by the original P-1 in 2003 but presumably was done with a buggy version of Prime95.

My kind of fun, for the moment.

[URL="https://www.mersenne.ca/exponent/4217750177"]https://www.mersenne.ca/exponent/4217750177[/URL]

It already had one factor, now it has four more.

All within 1 bit of each other?? That's... unusual.

[QUOTE=James Heinrich;567804]All within 1 bit of each other?? That's... unusual.[/QUOTE]

...fascinating... (C)

[M]M27152453[/M] has a 77.503-bit (24-digit) factor: [URL="https://www.mersenne.ca/M27152453"]214211625581311913643047[/URL] (P-1,B1=1350000,B2=89100000)


Long live large B2!

k= 7 × 83 × 173 × 577 × 68 015 191

Indeed!!!

[QUOTE=firejuggler;568706]
Long live large B2!
[/QUOTE]

[M]M102202943[/M] has a 110.005-bit (34-digit) factor: [url=https://www.mersenne.ca/M102202943]1302388182362272479207770608381153[/url] (P-1,B1=1500000,B2=45000000,E=12)

min B2 = 24 878 501

[M]M102057829[/M] has a 100.217-bit (31-digit) factor: [url=https://www.mersenne.ca/M102057829]1473595630881614096459261244097[/url] (P-1,B1=1500000,B2=91500000)

min B2 = 63 240 223

[QUOTE=nomead;567803]
[URL="https://www.mersenne.ca/exponent/4217750177"]https://www.mersenne.ca/exponent/4217750177[/URL]

It already had one factor, now it has four more.[/QUOTE]

67.472 - 66.121 = 1.351

By that measure, then, these four are bunched up even closer:
[URL="https://www.mersenne.ca/exponent/4241699879"]https://www.mersenne.ca/exponent/4241699879[/URL]

67.221 - 65.933 = 1.288 :smile:

P-1 found a factor in stage #2, B1=736000, B2=19894000.
UID: Jwb52z/Clay, M102192683 has a factor: 1528515278715554871122431 (P-1, B1=736000, B2=19894000)

80.338 bits.

P-1 found a factor in stage #1, B1=737000.
UID: Jwb52z/Clay, M102256103 has a factor: 417298926313351006345081 (P-1, B1=737000),

78.465 bits.

TF Result:

UID: stargate38/GTX1650, M4197560041 has a factor: 7284080534216661181663 [TF:31:73:mfaktc 0.21 75bit_mul32_gs]

72.625 bits; k=3*4337*4561*14621

I pulled these from my results on Primenet:

[QUOTE]M103813579, Factor: 19610018312363450480303 / TF: 74-75
M103811881, Factor: 37646989331843629835057 / TF: 74-75[/QUOTE]I had been running GPUto72 for a couple of weeks. 23 digits each. I did not bother with bits.

[QUOTE=storm5510;569744][QUOTE]TF: [b]74[/b]-75[/QUOTE]23 digits each. I did not bother with bits.[/QUOTE]Let me guess. Umm, 74.xxx bits perhaps?

Props to Kriesel for knocking me out of the Top 500 with this enormous factor!!!

[M]M101837677[/M] has a 128.604-bit (39-digit) factor: [url=https://www.mersenne.ca/M101837677]517050261390286174198141026167350661719[/url] (P-1,B1=1000000,B2=30000000)

[QUOTE=retina;569745]Let me guess. Umm, 74.xxx bits perhaps?[/QUOTE]

If you want to look at it this way, yes. GPUto72 is currently running to 76 bits, a prep for the next step. Before, this would be P-1, but now, I am not sure.

[QUOTE=Runtime Error]Props to Kriesel for knocking me out of the Top 500 with this enormous factor!!![/QUOTE]

I too have found a 39-digit factor. This was on 5/05/2019. Mine was ECM. M83621. It is [URL="https://www.mersenne.org/report_exponent/?exp_lo=83621&exp_hi=&full=1&ecmhist=1"]here[/URL]. I never checked on any list to see if it was there. Doing so never seemed important at the time.

[QUOTE=storm5510;569786]I too have found a 39-digit factor... I never checked on any list to see if it was there.[/QUOTE]It's [url=https://www.mersenne.ca/userfactors/ecm/1/bits#M83621]#385[/url] on the biggest ECM factors [COLOR="DarkOrchid"](edit: of Mersenne numbers)[/COLOR] list. :smile:

[QUOTE=James Heinrich;569789]It's [URL="https://www.mersenne.ca/userfactors/ecm/1/bits#M83621"]#385[/URL] on the biggest ECM factors list [U]for mersenne numbers[/U]. :smile:[/QUOTE]
Fixed it for you. As opposite to biggest ever, [URL="https://members.loria.fr/PZimmermann/records/top50.html"]openweight[/URL].

P-1 found a factor in stage #2, B1=737000, B2=19917000.
UID: Jwb52z/Clay, M102307399 has a factor: 376759813552401417250697953 (P-1, B1=737000, B2=19917000),

88.284 bits.

[QUOTE=James Heinrich;569789]It's [URL="https://www.mersenne.ca/userfactors/ecm/1/bits#M83621"]#385[/URL] on the biggest ECM factors [COLOR=DarkOrchid](edit: of Mersenne numbers)[/COLOR] list. :smile:[/QUOTE]

Thank you for the link. 70 digits at the top. That is quite amazing. :smile:

P-1 found a factor in stage #2, B1=738000, B2=19926000.
UID: Jwb52z/Clay, M102357631 has a factor: 321965205924875189306321369 (P-1, B1=738000, B2=19926000),

88.057 bits.

I found a very easy one (randomly selected a nice number and spent <1 GhzD effort) in M3331331 yesterday, but the number was factored previously: [url=http://mersenne.ca/M3331331]mersenne.ca[/url], [url=https://www.mersenne.org/report_exponent/?exp_lo=3331331&full=1]Primenet Details[/url]. What bothers me is that the same PRP residue is identical for the PRP test with 1 factor and the PRP test with 2 factors? This is a bug, isn't it?

The factor I'm most proud of is this lucky 118bit one in [url=https://www.mersenne.ca/exponent/70553939]M70553939[/url] which I found in normal LL/PRP testing.

[QUOTE=gLauss;570211]This is a bug, isn't it?
[/QUOTE]
Yep. Bug for sure, unless you used gpuowl, which totally ignores the factors, and does prp for the whole Mxx, in which case both residues (and the semantic result, like the cofactor being PRP or not) are wrong. Right now, only P95/mprime can be used for PRP-CF and PRP-CF-DC. If you use gpuowl, it will not signal an error, but it will PRP the wrong number. I assume Mihai is working on this, either to include the PRP-CF option, or to give and error when worktodo line contains factors.

[QUOTE=LaurV;570212]Yep. Bug for sure, [/QUOTE]
I used mprime and the residue B786DF1732AE7343 is the one which mprime reported in the results.json.txt. I filed a bug in the [url=https://mersenneforum.org/showthread.php?t=26448]Primenet section[/url].

[QUOTE=LaurV;570212]Yep. Bug for sure[/QUOTE]

No. P95 calculates 3^(Mp+1) == 3^(f+1) to prp test Mp/f. So the residue produced is always the same.

By calculating 3^(Mp+1), you can just do repeated squaring (more efficient), which also allows GEC / CERT capability.

[QUOTE=gLauss;570211]The factor I'm most proud of is this lucky 118bit one in [url=https://www.mersenne.ca/exponent/70553939]M70553939[/url] which I found in normal LL/PRP testing.[/QUOTE]

It looks like Brent-Suyama helped you there.

[QUOTE=axn;570218]No. P95 calculates 3^(Mp+1) == 3^(f+1) to prp test Mp/f. So the residue produced is always the same.
By calculating 3^(Mp+1), you can just do repeated squaring (more efficient), which also allows GEC / CERT capability.[/QUOTE]Does this mean one could fake the residue for a PRP test with a different number of cofactors (trivial, it's always the same), but one would not be able to (so easily) fake the proof?

Found a 94.6 bit factor for [M]122227733[/M], not too bad...

P-1 found a factor in stage #2, B1=738000, B2=19943000.
UID: Jwb52z/Clay, M102443659 has a factor: 9267323975458581946834423 (P-1, B1=738000, B2=19943000),

82.938 bits.

Massive B2
 

[M]M103012487[/M] has a 98.476-bit (30-digit) factor: [url=https://www.mersenne.ca/M103012487]440774470073643783648685727201[/url] (P-1,B1=2000000,B2=132000000)

I think this is the largest B2 that I've found!!! Not a bad sized factor either :smile:

[$]k = 2^4 × 5^2 × 7 × 17 × 19 × 151 × 160,087 × 97,859,501[/$]

[QUOTE=kruoli;570221]It looks like Brent-Suyama helped you there.[/QUOTE]
Yes, it did. I tried to understand why this large factor 195509617 of k for my factor of [url=https://www.mersenne.ca/exponent/70553939]M70553939[/url] has been found with e=12 Brent-Suyama and a B2 of only 13222500. As far as I understand it after reading [url=https://www.rieselprime.de/ziki/Brent-Suyama_extension]this explanation[/url], I think it must be because 195509617 happens to divide a larger polynomial. So I tried to find this larger polynomial with the Python code below, but the output is empty, so I must have done something wrong ...
[CODE]
#!/usr/bin/python

n=70553939
factor_of_k=195509617
B2=13222500
e=12
primorial = 2310

for i in range(0,B2//primorial+1):
for j in range(1,primorial,2):
# test if 195509617 divides (2310*i + j)^12 - 1 (we only need to do it for uneven j)
if pow(primorial*i+j, e, factor_of_k) == factor_of_k-1:
print(f"{factor_of_k} divides ({primorial}*{i}+{j})**{e}-1")
[/CODE]

The poly is (2310*i)^12-j^12, and only j that is relatively prime to 2310 need to be considered. Actually, now that I think about it, could be (4320*i)^12-j^12

EDIT:- If you've used the new 30.4 version, then j can be much bigger than primorial

EDIT2:- i=5413, j=19891, D=2310 works

[QUOTE=axn;570911]The poly is (2310*i)^12-j^12, and only j that is relatively prime to 2310 need to be considered. Actually, now that I think about it, could be (4320*i)^12-j^12[/QUOTE]
Thanks, that was in fact my stupid mistake: Now it works:
[CODE]
factor_of_k=195509617
B2=13222500
e=12
for primorial in [30,210,2310]:
for i in range(0,B2//primorial+1):
# test 2310*k + 1, 2310*k + 3, 2310*k + 5, ...
# (didn't bother to check only co-prime j
for j in range(0,primorial):
if pow(primorial*i, e, factor_of_k) == pow(j, e, factor_of_k):
print(f"{factor_of_k} divides ({primorial}*{i})**{e}-{j}**{e}")

[/CODE]
[CODE]
$ python brent.py
195509617 divides (30*0)**12-0**12
195509617 divides (210*0)**12-0**12
195509617 divides (2310*0)**12-0**12
195509617 divides (2310*5183)**12-423**12
[/CODE]
So B2 had to be at least 2310*5183 = 11972730 and mprime had chosen B2=13222500 :) (It was with an older version of mprime, please note that the factor was found a long time ago).
Maybe I need to take a look into the source code if I want to 100% understand it. But I think it's fine for now.

Hmmm... 423 is not relatively prime to 2310, so that is not a valid combo.

:confus:

Are you sure it was D=2310, E=12? D=210 is another option, as is E=6.

[QUOTE=axn;570915]Hmmm... 423 is not relatively prime to 2310, so that is not a valid combo.[/QUOTE]
You are right. I'm confused, too. I don't have the line from results.txt anymore, but [url=https://www.mersenne.ca/exponent/70553939]mersenne.ca[/url] definitely tells me that it was found with e=12. I can't find a valid relation, regardless of the primoral I use. There must be some aspect of Brent-Suyama which I didn't get so far. As I said, I would need to deep dive into the source code in order to explain this "black magic". It is not this important and I don't want to hijack this thread with my stupid questions :)
[CODE]
#!/usr/bin/python
from math import gcd
#n=70553939
factor_of_k=195509617
B1=645000
B2=13222500
e=12
def is_coprime(a,b):
return gcd(a,b) == 1
for primorial in [6,30,210,2310,4620]:
coprimes = [i for i in range(1,primorial) if is_coprime(i,primorial)]
print(f"Trying with primorial {primorial}, phi({primorial})={len(coprimes)} (number of coprimes)")
for i in range(B1//primorial,B2//primorial+1):
for j in coprimes:
for e in [2,6,12]:
if pow(primorial*i, e, factor_of_k) == pow(j, e, factor_of_k):
[/CODE]
[CODE]
Trying with primorial 6, phi(6)=2 (number of coprimes)
Trying with primorial 30, phi(30)=8 (number of coprimes)
Trying with primorial 210, phi(210)=48 (number of coprimes)
Trying with primorial 2310, phi(2310)=480 (number of coprimes)
Trying with primorial 4620, phi(4620)=960 (number of coprimes)
[/CODE]

[QUOTE=gLauss;570925]I don't have the line from results.txt anymore[/QUOTE]The submitted result line was:
[c]UID: gLauss, M70553939 has a factor: 397468376254043223116452263596173351 (P-1, B1=645000, B2=13222500, E=12), AID: <removed>[/c]

[QUOTE=Viliam Furik;559636][M]M10017487[/M] has a 162.539-bit (49-digit) [b]composite[/b] (P23+P27) factor: [url=https://www.mersenne.ca/M10017487]8492545109166755533258311668299806208565163467423[/url] (P-1,B1=5000000,B2=150000000)

When I found this beauty in results.txt, I said: "Well, that will be composite...".

It was... :rant:[/QUOTE]

It happened again...

[M]M42654757[/M] has a 177.384-bit (54-digit) [b]composite[/b] (P24+P31) factor: [url=https://www.mersenne.ca/M42654757]249962766200012947561203808756653177525031174447055441[/url] (P-1,B1=2000000,B2=60000000)

[QUOTE=Viliam Furik;571324]It happened again...

[M]M42654757[/M] has a 177.384-bit (54-digit) [b]composite[/b] (P24+P31) factor: [url=https://www.mersenne.ca/M42654757]249962766200012947561203808756653177525031174447055441[/url] (P-1,B1=2000000,B2=60000000)[/QUOTE]
A 99 bit factor is nothing to sneeze at! And getting a 77 bit one on the side is cool.

P-1 found a factor in stage #2, B1=739000, B2=19974000.
UID: Jwb52z/Clay, M102606121 has a factor: 286278308342764813608289 (P-1, B1=739000, B2=19974000),

77.922 bits.

M14021941 has a factor: 658712964914137545610873 (P-1, B1=550000, B2=50000000, e=12, n=800K CUDAPm1 v0.22)

Not a very big one, but ...

Brent-Suyama:
P-1 = 658712 964914 137545 610872 = 2^3 × 3 × 23 × 29 × 41 × 67 × 14,021,941 × 1,068,297,817

[quote][M]M74297[/M] has a 115.150-bit (35-digit) factor: [url=https://www.mersenne.ca/M74297]46093402217811334422500629825749239[/url] (ECM,B1=3000000,B2=300000000,Sigma=861422999935301)[/quote]Not my factor, but has a 98-bit prime [i]k[/i].

[M]M672151[/M] has a 92.364-bit (28-digit) factor: [URL="https://www.mersenne.ca/M672151"]6371270358962852152708374071[/URL] (ECM,B1=250000,B2=25000000,Sigma=1287986895578128)

Is "sigma" a recent addition to the BBcode converter? I don't remember seeing it before.

[QUOTE=storm5510;572516]Is "sigma" a recent addition to the BBcode converter? I don't remember seeing it before.[/QUOTE]I added maybe 3 months ago.

Not big enough for Top 500, but still pretty big!

[M]M102885221[/M] has a 116.736-bit (36-digit) factor: [url=https://www.mersenne.ca/M102885221]138350038577290668825510687167523289[/url] (P-1,B1=1200000,B2=73200000)

[M]M32420933[/M] has a 104.770-bit (32-digit) factor: [URL="https://www.mersenne.ca/M32420933"]34588826421437796964455285406873[/URL] (P-1,B1=1000000,B2=1000000)

:yzzyx:

[M]M27133867[/M] has a 103.452-bit (32-digit) factor: [url=https://www.mersenne.ca/M27133867]13873846040230053282547473883439[/url] (P-1,B1=1350000)

P-1 found a factor in stage #1, B1=742000.
UID: Jwb52z/Clay, M103030289 has a factor: 123545495958101009290577 (P-1, B1=742000),

76.709 bits.

User Bruno Victal found a top 500 factor:
7121 has a factor: 981699625212423826313904772778259971143
129.529 bits, 39 digits
[FONT="Comic Sans MS"][I][B]k[/B][/I][/FONT] 68929899256594848077089227129494451 = 3 × 7 × 61 × 53809445165179428631607515323571

It does happen!
 

[CODE]M3719987 has a factor: 881990415365354042303 [TF:69:70:mfaktc 0.21 barrett76_mul32_gs]
M3719987 has a factor: 594140183196613372391 [TF:69:70:mfaktc 0.21 barrett76_mul32_gs]
found 2 factors for M3719987 from 2^69 to 2^70 [mfaktc 0.21 barrett76_mul32_gs]
[/CODE]

[CODE]M3896351 has a factor: 623156986806917144446428743177311121238033821208621841 (P-1, B1=15000000, B2=750000000)[/CODE]
623156986806917144446428743177311121238033821208621841 = 50056000151283039160199 x 12449196598281221990483347809959

Interestingly, both factors are B1-smooth.

Have you skipped stage 1 GCD?

Yes, with the intent to find maximum number of factors for the effort spent.

As if to prove my point:
[CODE]M3897389 has a factor: 45181493770845059783464463031892083814410916646456447555354707802319544943 (P-1, B1=15000000, B2=750000000)[/CODE]
The composite splits as 29328238810511654808943052108623 x 1540545753966357318407650279153419100591841

The smaller one is a B1-only factor, whereas the larger one is a B2 factor. Incidentally, the larger one is 140.1 bits and will slot in at #28 in [URL="https://www.mersenne.ca/userfactors/pm1/1/bits"]the list[/URL] -- my second biggest!

Congratulations! :smile: I did not want to judge you with your reasoning in my last post.

We would call something like that figuratively "Kaventsmann" in German.

[QUOTE=kruoli;573398]Congratulations! :smile: I did not want to judge you with your reasoning in my last post.[/QUOTE]
FWIW, I didn't interpret it as being judgemental.

It is just that, it was too funny that as soon as I explained my reasoning, I got an example. In the past 10 months or so running deep P-1, I don't think I have seen this situation occur (a mix of stage1 & stage 2 factors being found together)

[QUOTE=axn573323]45181493770845059783464463031892083814410916646456447555354707802319544943[/QUOTE]

74 digits, if I counted correctly. Quite impressive. If I may ask, what did you run this with and how long did it take?

[QUOTE=storm5510;573502]74 digits, if I counted correctly. Quite impressive. If I may ask, what did you run this with and how long did it take?[/QUOTE]

1 core on a Ryzen 5 3600 (running in Eco mode). Took about 8.5 hours, running mprime 30.4. Allocated about 4GB of memory.

[QUOTE=axn;573397]Incidentally, the larger one is 140.1 bits and will slot in at #28 in [URL="https://www.mersenne.ca/userfactors/pm1/1/bits"]the list[/URL] -- my second biggest![/QUOTE]Sorry about that, because your composite factor was >200 bits it broke out of my automated factoring code and while I remembered to delete the composite from the records table I forgot to put your prime factors back in. :redface:
I have done so now, and indeed the larger of the two is at #28 in the [url=https://www.mersenne.ca/userfactors/pm1/1/bits]top P-1 factors[/url], and #2 for [url=https://www.mersenne.ca/userfactors/any/1077/bits]top [i]axn[/i] factors[/url].

[QUOTE=axn;573509]1 core on a Ryzen 5 3600 (running in Eco mode). Took about 8.5 hours, running mprime 30.4. Allocated about 4GB of memory.[/QUOTE]

My son has a Ryzen 5 3600. 6 cores / 12 threads. Why only one core?

[QUOTE=storm5510;573772]My son has a Ryzen 5 3600. 6 cores / 12 threads. Why only one core?[/QUOTE]

Those small exponents give the highest throughput when you set it to 6 workers, 1 core per worker.

[QUOTE=storm5510;573772]My son has a Ryzen 5 3600. 6 cores / 12 threads. Why only one core?[/QUOTE]

1 core per worker, 6 workers, all running P-1.

EDIT:- What Viliam said.

[QUOTE=axn;573780]1 core per worker, 6 workers, all running P-1.

EDIT:- What Viliam said.[/QUOTE]

Ah, I get it now. I have done something similar with Prime95 in the past, but not to this extent. 2 workers using 2 cores each on an i7. IIRC, each worker will use the memory setting in [I]local.txt. [/I]In my case, it was 4,096. 8,192 for both.

Not a big factor but just barely at a new TF bit level
 

28385759
Factor: 4728836973118701446897 / TF: 72-73*
72.002 Bits!!!

[QUOTE=petrw1;574000]28385759
Factor: 4728836973118701446897 / TF: 72-73*
72.002 Bits!!![/QUOTE]

I'm guessing that was worth about 0.001 GHz-days

[M]M27142097[/M] has a 174.143-bit (53-digit) [b]composite[/b] (P27+P27) factor: [url=https://www.mersenne.ca/M27142097]26436212642162007070517822654531755460254859231089553[/url] (P-1,B1=1350000,B2=109350000)

[QUOTE=slandrum;574003]I'm guessing that was worth about 0.001 GHz-days[/QUOTE]Mfaktc (and most factoring programs) don't look for factors in order of bitsize but by class spread throughout the target range. In this case the factor is found in class 3412 (of 4620) so it took ~74% of the full-range effort to find even though it happened to be right at the bottom of the range.

[QUOTE=slandrum;574003]I'm guessing that was worth about 0.001 GHz-days[/QUOTE]

0.0666 (Diabolical)

[QUOTE=James Heinrich;574030]Mfaktc (and most factoring programs) don't look for factors in order of bitsize but by class spread throughout the target range. In this case the factor is found in class 3412 (of 4620) so it took ~74% of the full-range effort to find even though it happened to be right at the bottom of the range.[/QUOTE]

74% of the work for 0.2% of the credit.
That's ok sometimes it's the other way around.

[QUOTE=petrw1;574040]74% of the work for 0.2% of the credit.
That's ok sometimes it's the other way around.[/QUOTE]I couldn't remember (and didn't bother to look up) if mersenne.org gives proper class-based credit or just takes the lazy approach, apparently it's the latter. For an individual assignment it's unfair, but on average as you say it all balances out.

IIRC, I asked this in the past, as I got some minuscule credit, close to zero, for a factor and I couldn't figure out why, as it was not on one of the first classes, mfaktc still had to do some work to get the factor. I think George replied something along the lines that PrimeNet gives TF credit class-based, except that the classes are P95-like, and not mfaktc-like. P95 splits the classes differently, whatever that means, maybe he can clarify. On average, this doesn't matter. As Wayne said, sometimes that is the other way around.

[QUOTE=LaurV;574058]P95 splits the classes differently, whatever that means, maybe he can clarify.[/QUOTE]I believe Prime95 uses 420 classes whereas mfakt[i]x[/i] uses 4620 classes (except for the less-classes version/setting when it also uses 420).

Well, it could be easily checked in which class the factors were, in both cases.

[QUOTE=LaurV;574062]Well, it could be easily checked in which class the factors were, in both cases.[/QUOTE]3412 / 4620
52 / 420

So, you would get about 70% of the NF credit with mfaktc, unless you TFed the whole bit (and no "star" is sent), but you would only get about 12% of the NF credit if P95 indeed uses 420 classes. More or less, as the space between the classes is not even. Better calculus would take in consideration modularity of p to 420 and 4620 and display x/96 and x/960 respectively, instead of x/420 and x/4620. No calculation done, only arguing :razz: the excuse is that it's 1:20 AM here. Going to bed. :yawn:

[QUOTE=James Heinrich;574061]I believe Prime95 uses 420 classes whereas mfakt[i]x[/i] uses 4620 classes (except for the less-classes version/setting when it also uses 420).[/QUOTE]

Prime95 (and Primenet's credit calculation) uses 16 mod 120 classes.

My only suggestion would be: if I TF the entire bit level regardless of the factor size I should get full credit ... because if someone later wants to find more factors they don't need to redo this bit level. Do I correctly assume mfaktc/Prime95 does not retain classes complete on a partial TF for later continuation?

[QUOTE=petrw1;574090]if I TF the entire bit level regardless of the factor size I should get full credit[/quote]You do (manual results form was changed several months ago to detect and handle this).
[QUOTE=petrw1;574090]Do I correctly assume mfaktc/Prime95 does not retain classes complete on a partial TF for later continuation?[/QUOTE]It [i]could[/i] in theory be derived from the result line, finding out what class the factor was found in and continuing from there. But neither software implements that.

[QUOTE=James Heinrich;574092]You do (manual results form was changed several months ago to detect and handle this).[/quote]


:tu:

P-1 found a factor in stage #2, B1=743000, B2=20368000.
UID: Jwb52z/Clay, M103164703 has a factor: 10394318420108355367002377 (P-1, B1=743000, B2=20368000).

83.104 bits.

Starts with 595959
 

28336753 F 2021-03-21 22:40 Factor: [U][B]595959[/B][/U]2039933211534161 / TF: 72-73

Congrats, triple 59, next one you will find will start with a quadruple 69... :razz:

Another nice composite
 

[CODE]M3865481 has a factor: 93787084544353687348484146830436095506958398058547079607725479 (P-1, B1=15000000, B2=750000000)[/CODE]
Splits as 220078042351889861586169 x 426153756831381209955800547030419928991

124 bits
 

42651893 F-PM1 Factor: 1627638207025330060517196929537 / (P-1, B1=1500000, B2=45000000)

[url]https://www.mersenne.ca/exponent/42650347[/url]

re: Post 1831

[QUOTE=James Heinrich;574092]You do (manual results form was changed several months ago to detect and handle this). [/QUOTE]

Seems it doesn't:

[CODE]Manual testing 28722943 F 2021-04-02 22:40 0.0 Factor: 4578986428371835478041 / TF: 71-72 15.9100
Manual testing 28723249 F 2021-04-02 22:40 0.0 Factor: 3416851867143956961289 / TF: 71-72 8.8773
Manual testing 28725779 F 2021-04-02 22:40 0.0 Factor: 3325594725067066329023 / TF: 71-72 8.2263
Manual testing 28721831 NF 2021-04-02 22:40 0.0 no factor from 2^71 to 2^72 16.6513[/CODE]

[QUOTE=petrw1;575031]Seems it doesn't[/QUOTE]Sorry, you're right. The change I was thinking of relates to detecting whether the result claims to be full-range TF or not, and some related code that handles composite factors found by TF, but the actual PrimeNet code that calculates and applies credit is outside my zone-of-control, and does not currently have any mechanism for specifying whether a range was complete or not. The data is available to the manual results form, it just can't pass that information on to where the credit is calculated and applied. Such a change would need to be applied at the George level.

[M]M27151489[/M] has a 76.836-bit (24-digit) factor: [url=https://www.mersenne.ca/M27151489]134831419346216729059463[/url] (P-1,B1=1350000,B2=109350000)

low bit but k= 7 × 11 × 349 337 × 92 306 471 , really close to my B2 bound

Double
 

[url]https://www.mersenne.org/report_exponent/?exp_lo=28190299&full=1[/url]


Factor: 4299246979573209796361 / TF: 71-72
Factor: 4001656651216207394857 / TF: 71-72

0.1 bits apart

Found a new record for me

[M]M27155813[/M] has a 112.563-bit (34-digit) factor: [url=https://www.mersenne.ca/M27155813]7669084564727955238545079945517857[/url] (P-1,B1=1350000,B2=109350000)

P-1 found a factor in stage #2, B1=746000, B2=20430000.
UID: Jwb52z/Clay, M103478927 has a factor: 118012953390073941784591 (P-1, B1=746000, B2=20430000).

76.643 bits.