P1 found a factor in stage #2, 1=2000000, B2=6733146420.
[URL="https://www.mersenne.ca/exponent/534923"]M534923[/URL] has a factor: 550097583190851024327654398832916947049 (P1, B1=2000000, B2=6733146420) 128.693 bits (P39) 
Factor: 215988199037237139637321 / (P1, B1=518000, B2=13589000)
[M]117115511[/M] This one is interesting only in that it was about the smallest factor that it could have found at 77.5 bits (the exponent had been TF'd to 77 bits). 
Had a lucky ECM streak on unfactored exponents recently, usually find 1 factor every couple weeks but have got 2 factors within a few hours of each other:
M214783 has a factor: 1102834494064669506004266650004828269423 / (ECM curve 17, B1=3000000, B2=6616119510, Sigma=137844928612264) (129.696 bits, 40 digits, new personal record largest factor) M210491 has a factor: 1680490771184651242949512447428919 / (ECM curve 11, B1=3000000, B2=6616119510, Sigma=575255113699867) (110.373 bits, 34 digits) 
Edit: Make that 3, this just happened aparrently:
M208073 has a factor: 3731074311071089639450741837271 (ECM curve 35, B1=3000000, B2=6616119510) 
Found a 110bit factor on a wave front exponent!
min B1 = 1,000,037 min B2 = 545,850,313 [M]M114785129[/M] has a 110.863bit (34digit) factor: [url=https://www.mersenne.ca/M114785129]2361477100582561776755612373583993[/url] (P1,B1=1400000,B2=1001933790) 
P1 found a factor in stage #2, B1=537000, B2=19025622.
UID: Jwb52z/Clay, M119602183 has a factor: 39769121872136784387765097 (P1, B1=537000, B2=19025622) 85.040 bits. 
Nice 100 bit P1 factor: [CA]119636903[/CA] has a factor: 1455962897408551638312586078553

Another one joins the club (bites the dust)
M736647071 has a factor: 19251950982339179681312159 (TF 8384)
A new member of a relatively small group of Mersenne's with 10 (or more) known factors. 
UID: Jwb52z/Clay, M119686603 has a factor: 194945427614502977436457 (P1, B1=537000)
77.367 bits. 
I've been amusing my sorry little butt by TF'ing way down in 2M. Also some P1.
My success rate on the TF has been very low (as expected). But today I found [URL="https://www.mersenne.ca/exponent/2028749"]this[/URL]. 
M2614303 has factor 94286373215560002099130008156415246687079887097 (156.04 bits)
k = 2^2 * 23 * 89 * 103 * 4423 * 17053 * 267517 * 3876497 * 5110717 * 53488147 think this is my biggest factor; I've found other large factors with P1 but they were composite 
[QUOTE=KingKurly;622637]think this is my biggest factor[/QUOTE]It [url=https://www.mersenne.ca/userfactors/pm1/845/bits]is[/url].
Nice factor (that the previous 9 P1 attempts failed to find). 
[QUOTE=KingKurly;622637]M2614303 has factor 94286373215560002099130008156415246687079887097 (156.04 bits)
k = 2^2 * 23 * 89 * 103 * 4423 * 17053 * 267517 * 3876497 * 5110717 * 53488147[/QUOTE] I just checked, and it's also the [url=https://www.mersenne.ca/userfactors/pm1/1/bits]18th largest P1 factor ever found[/url] for a Mersenne number. 
M9001 has a factor: 26853085360471857637409520958360644587565839 (ECM curve 52, B1=11000000, B2=99324315090)
Sigma=3946644149112759 gives this a group order 2^3*3*5*11*254147*964721*1160987*1563967*10243213*4461104491 Barely within the B1 bounds. Quite a way within the B2 bounds, but not within prev30.9 mprime bounds :) 
Denial strikes again:
[quote][M]M8111[/M] has a 150.939bit (46digit) factor: [url=https://www.mersenne.ca/M8111]2736378679052345545917895072180598558105496631[/url] (ECM,B1=11000000,B2=99324315090,Sigma=7000555281870627)[/quote] [QUOTE=Denial140;623505]Sigma=3946644149112759 gives this a group order 2^3*3*5*11*254147*964721*1160987*1563967*10243213*4461104491[/QUOTE]How do you translate Sigma into that factorization? (pretend I'm a math simpleton, for I am) 
[QUOTE=James Heinrich;623648]How do you translate Sigma into that factorization? (pretend I'm a math simpleton, for I am)[/QUOTE]
I'm afraid I don't yet understand the maths behind calculating the group order (if anyone has a reference or something to search, I'd enjoy learning it, but it hasn't been a priority to seek out myself), but there are a few tools around to calculate it automatically. One is [URL="http://factordb.com/groupcalc.php"]factordb's group order calculator[/URL], or there is a MAGMA script for it [URL="https://www.mersenneforum.org/showthread.php?t=14184"]here[/URL]. For the factor of M8111, we get required B1=3752981, and B2=16158607739~=16x10^9. 
Woah again? So many factors :O
I am currently extending t40 on unfactored exponents to exponent=6e5 (previously was at 5.2e5 with some stragglers below 5e5). Almost halfway there, no factors yet, I don't expect to find any but then again I don't know what the expected factor chance is. If I do get one this place will be the first to know =) 
P1 found a factor in stage #2, B1=538000, B2=19053972.
UID: Jwb52z/Clay, M119785943 has a factor: 1244924310880748724624143 (P1, B1=538000, B2=19053972) 80.042 bits. 
Finally got a factor in 0.05M:
M58711 has a factor: 3601049884575574689964727254469924804359 (ECM curve 18, B1=11000000, B2=326123803005, Sigma=682428721328954), 131 bits Reduces to group order 2^2 · 3^2 · 189913 · 408923 · 1060469 · 3162659 · 4625119 · 83034227 inside B1 by a factor of almost 3 and inside B2 by a factor of almost 4000 (!) 1 down, 32 more exponents to go to reach less than 1000 unfactored in 0.0M range. 
Nice factor! Nice goal!

True but the effort required to reach said goal is immense... I would need significant help if it were to be achieved anytime soon and even then it's still a tall order. Took my computer 4 months to grab a single factor and that was the low hanging fruit.....

If you want help, I suggest starting a thread for the topic.
I'm game to find a factor in that range to help your trek. 
I have queued some P1 assignments in 60,000 < p < 100,000 that still have rather smallish B2 for the range. I should complete those in about two weeks. I hope to find one factor in that group. I have my eye on additional targets in that range, so coordination might be smart.

P1 found a factor in stage #2, B1=538000, B2=19065312.
UID: Jwb52z/Clay, M119859749 has a factor: 33194967377827180019537297 (P1, B1=538000, B2=19065312) 84.779 bits. 
P1 found a factor in stage #2, B1=538000, B2=19065312.
UID: Jwb52z/Clay, M119867203 has a factor: 2481086913583151895746080393 (P1, B1=538000, B2=19065312) 91.003 bits. It's been a long time since I've found 2 factors so close together. 
P1 found a factor in stage #2, B1=538000, B2=19073754.
UID: Jwb52z/Clay, M119907379 has a factor: 1872665032306892551775755247951 (P1, B1=538000, B2=19073754) 100.563 bits. I haven't had a factor this big in a while. 
Found the 5th known factor of [M]M20983[/M] with B1=3M:
421943541531764594131178450223363676463 39 digits, 129 bits With that sigma it could have been found with B1=1M: GO = 2^5 · 3^2 · 7 · 199 · 331 · 587 · 881 · 1229 · 43037 · 98869 · 530333 · 2215471 Which makes me wonder, for a factor p, is there for every sufficiently small q an elliptic curve such that the group order is qsmooth? edit: Some thoughts. If the group order is always smaller than the factor p and if every curve produces a unique group order, then the answer would be "yes", I think. 
[QUOTE=bur;625433]Which makes me wonder, for a factor p, is there for every sufficiently small q an elliptic curve such that the group order is qsmooth?[/QUOTE]
If I'm understanding you correctly then no  Hasse's theorem tells us that the group order is between (p+1)  2sqrt(p) and (p+1) + 2sqrt(p). For any fixed q, the numbers that are qpowersmooth are bounded, so for sufficiently large p they will never be found with B1=q. 
[QUOTE=Denial140;625438]If I'm understanding you correctly then no  Hasse's theorem tells us that the group order is between (p+1)  2sqrt(p) and (p+1) + 2sqrt(p). For any fixed q, the numbers that are qpowersmooth are bounded, so for sufficiently large p they will never be found with B1=q.[/QUOTE]
In practice the largest B1powersmooth number is HUGE [CODE] import primesieve import math def bound(B1): primes = primesieve.primes(B1) b1_smooth = [p ** math.floor(math.log(B1, p)) for p in primes] print(B1, sum(map(math.log2, b1_smooth))) bound(10 ** 4) bound(10 ** 5) bound(10 ** 6) [/CODE] B1 log_2(product(prime ^ floor(log_prime(B1)))) 10000 14446 100000 144344 1000000 1442099 I believe this mean that you could find (in theory) a prime with group order up to ~14,446 bits using only B1=10^4. I think in an old gmpecm thread someone found several 60 digit factors with B1 < 100,000 (they did have a final large B2). There's a summary of how to search for these fake factors in [url]https://homepages.cwi.nl/~herman/Zimmermann.pdf[/url] 
[M]M7841[/M] has a 143.242bit (44digit) factor: [url=https://www.mersenne.ca/M7841]13185234429279006450961428192075425254794689[/url] (ECM,B1=43000000,B2=893921898870,Sigma=770783052401581)
Group order 2^2 . 3^2 . 29 . 6221 . 265607 . 2361977 . 4714819 . 11347471 . 60485025547 Just barely out of reach of the B1=11000000 I was running before... good thing I switched, I guess :) It would've fit in B2 being used for either choice of B1. Unfortunately when I woke up I found the PRP test had already been run  I've noticed that it shows up in the mersenne.ca "get PRP work" for cofactors, and I think this is true in general. It's not a big deal but if it's easy to make this page give the usual couple of days grace period for the finder (of course this is not the right place but not worth a separate post) that would be appreciated. 
[QUOTE=Denial140;625697]I found the PRP test had already been run  I've noticed that it shows up in the mersenne.ca "get PRP work" for cofactors, and I think this is true in general. It's not a big deal but if it's easy to make this page give the usual couple of days grace period for the finder (of course this is not the right place but not worth a separate post) that would be appreciated.[/QUOTE]I'm not sure I quite understand this request (if warranted you can elaborate in the mersenne.ca thread). Data on mersenne.ca is naturally delayed hourstodays from mersenne.org  once your computer reports a factor it's likely very quickly picked up for PRPCF, probably by automatic PrimeNet assignment, nothing to do with mersenne.ca
Incidentally, I've updated the mersenne.ca [URL="https://www.mersenne.ca/json2bbcode.php"]JSONtoBBcode tool[/URL] to support ECM Group Order calculations:[quote][M]M7841[/M] has a 143.242bit (44digit) factor: [url=https://www.mersenne.ca/M7841]13185234429279006450961428192075425254794689[/url] (ECM,B1=43000000,B2=893921898870,Sigma=770783052401581) Group Order: 13185234429279006450961058357072166475195908 Group Order Factored: 2^2 * 3^2 * 29 * 6221 * 265607 * 2361977 * 4714819 * 11347471 * 60485025547 Bounds: B1 = 11 347 471 ; B2 = 60 485 025 547[/quote] 
It is much more likely that your PRPCF was intentionally poached; there are a couple of users that do that for every factor found below a certain limit despite GIMPS only hands out PRPCF assignments to others after a week (IIRC). The users that regularly do this should be penalised or prohibited to do this IMO. This steals the possibility from the one that found the factor to claim a potential PRP result.
I had suggested previously that Prime95 should optionally do a PRPCF when a new factor was found below a certain exponent limit before reporting the factor. I have never heard any responses on this. 
I see  thank you for letting me know about this.
I mentioned mersenne.ca because I've noticed that sometimes it has lowhanging cofactor PRP sooner than I'd expected after the factor find on the [URL="https://www.mersenne.ca/prp.php?show=3"]unknown (get work to do)[/URL] option for cofactor PRP testing. 
That is not poaching! Doing work that Primenet expressly makes available is contributing positively, especially given that most factor finders (at least above ~500,000) don't do the PRP. I am not sure if the mersenne.ca list has anything to do with this though surely James _could_ change it.
If you insist on ensuring you get the PRP, there's already an obvious way: manually submit the factor and the PRP at the same time. 
It is generally agreed, as far as I can tell, that the finder gets first dibs on the PRP check if they want it, and a grace period of a couple of days to allow for them to notice the discovery is a nice curtesy from others, even though it is not a strict requirement. I [I]believe[/I] that the server does not actually hand out these assignments during that period, although I don't want to try to track down where I read that right now.
Is it a big deal? In my case no, especially since the cofactor was not a PRP. It's just a bit of fun for me to see that (yet again) the cofactor is composite :) But I don't think it should be encouraged, and (if my belief about the server is true) it is tantamount to poaching, even if I am more fussed personally about finding the factor. 
[QUOTE=Andrew Usher;625793]That is not poaching! Doing work that Primenet expressly makes available...[/QUOTE]
Well, it sort of is [strike]poaching[/strike] playing outside of the rules because Primenet does not make the PRPCF assignment available for one week. 
Well, you've confirmed that it is supposed to work that way, and I guess I can see why. But if we know there are users that routinely do PRPCFs as soon as possible, it can't be a surprise when it happens  and if I cared, I'd do what I suggested  submit the factor and PRP result at the same time.
There are ways this could be prevented without compromising the database, but they would seem messy. Less so would be to change a future Prime95 per kruoli's suggestion above, but I would think to avoid complaints the option should be off by default and the maximum exponent configurable. 
[QUOTE=Prime95;625801]Well, it sort of is [strike]poaching[/strike] playing outside of the rules because Primenet does not make the PRPCF assignment available for one week.[/QUOTE]
Then [URL="https://www.mersenne.ca/prp.php?show=3"]mersenne.ca[/URL] shouldn't make them available, yes? 
It (mersenne.ca) is no platform to guide you in which work is available, because it cannot reserve anything via mersenne.org (the only site that has policymaking power in this case) and because it is not fully realtime. Since the usual rule is that you need an assignment ID (AID) to do a work unit, this is the only thing you should watch out for. If you are unable to get an AID for some work you want to do, it is either reserved/held back for someone else, unwanted, or in some cases bugged. If you think it is the latter, ask in the "Official Server Problems Thread" and it will be sorted out or deemed a feature, not a bug.

[QUOTE=Prime95;625801]Primenet does not make the PRPCF assignment available for one week.[/QUOTE]mersenne.ca now should also hide PRPCF for 7 days after the most recent factor is discovered. Let me know if it's not working as expected.

Got one:
ECM found a factor in curve #30, stage #2 Sigma=7954931777905094, B1=11000000, B2=52102380330. M99137 has a factor: 6459953914675791129553263498255728369 (ECM curve 30, B1=11000000, B2=52102380330) 31 to go to get under 1k on 0.0M. 
I was among the ones who requested this testing privilege period for the factorfinder, precisely because those who automatically got the freshly available PRPCF work have finished before I, or other factorfinders, have even noticed a factor was found. It is true that very few of us actually use this privilege period, but it was established so that those who do want to use it have opportunity to do so.
I could agree with shortening the period to say 5 days, but I believe it has a good purpose and should be honored. When people forget why the rules have been established, the rules lose their purpose. Just like in times of peace, when people forget about war, we forgot what led to the peace and take it for granted, and then we tend to lose it. We mustn't forget why the rules are the way they are and why we do what we do, whatever it may be. Si vis pacem, para pactum. 
[QUOTE=Viliam Furik;626394]It is true that very few of us actually use this privilege period, but it was established so that those who do want to use it have opportunity to do so.[/QUOTE]It's gradually going to become automatic:[QUOTE=Prime95;626284]30.11 build 1
 PRPCF done after new factor is found[/QUOTE] 
For smaller mersennes it looks like factordb performs a PRPCF almost immediately. No PRPCF result for the factor of M99137 has been reported to PrimeNet but on factordb when I checked a few hours ago it was aware of the factor and the fact that the cofactor was composite (I had not ran a PRPCF yet). Not really a big deal since it is outside of GIMPS and it seems no record of the test exists (publicly anyway).

[QUOTE=James Heinrich;626397]It's gradually going to become automatic:[/QUOTE]
Nice, I didn't notice that. I have not been paying much attention to things here lately. This automatic testing only increases the importance of the privilege period. I have an idea for resolving these credit conflicts of discovery. Just a prototype thought, so it needs some thinking and discussion before it can be considered as a proposition. When someone is assigned an exponent to test which turns up prime, but someone else has poached that result and got there first  or similarly, someone found a factor and someone else beat them to finding the PRP result  the wouldbe discoverer and the poacher discoverer could have a shared credit for the discovery (with the unofficial "boo" from the community to the poacher). The person who was assigned the test would have most probably found the prime (or PRP) if they finished the test first (chances of errors and abandoned tests are relatively miniscule, and should be presumed not present similarly to the principle of "innocent until proven guilty"). That is undeniable fact. The poacher has discovered the prime first. Also undeniable fact. And when the are two undeniable facts which don't quite agree, we can either argue both are to be considered false (indicating some contradiction as in proof by contradiction) or both true. Since both follow from the base principles of assignments and discoveries, in my opinion they should both be considered valid. If the poacher didn't work through GIMPS, that would be a different story since then there would be no poaching and the poacher would in fact be a rightful discoverer. But for the cases outside of GIMPS this discussion would be meaningless, so they don't matter much. What do you think, fellow Mersenne folk? 
Maybe you are misunderstanding the change, it is not that new factors will get distributed more quickly, instead the [I]discoverer's[/I] machine will automagically run the PRPCF run after a factor was found, so the grace period might not be necessary in this case. So it is much more likely that nobody can poach this, even if they try hard.

George can clarify the intent, but my impression was that the PRPCF was immediate and the factor result not submitted until the PRPCF is complete.

[QUOTE=kruoli;626453]Maybe you are misunderstanding the change, it is not that new factors will get distributed more quickly, instead the [I]discoverer's[/I] machine will automagically run the PRPCF run after a factor was found, so the grace period might not be necessary in this case. So it is much more likely that nobody can poach this, even if they try hard.[/QUOTE]
I do fully understand that. But if the test will be performed automatically, it can still be poached, since the test takes some time. The slower the machine, the more possibilties for poaching it. And if an automatic test gets poached often enough, well that's just a waste of computing time, no? Shortening the period according to the time it takes to do the PRPCF might be viable, but I think it should still be provided. EDIT: [QUOTE=James Heinrich;626455]George can clarify the intent, but my impression was that the PRPCF was immediate and the factor result not submitted until the PRPCF is complete.[/QUOTE] If that is the case, then yes, the privilege period would not be needed. 
[QUOTE=kruoli;626453] the [I]discoverer's[/I] machine will automagically run the PRPCF run after a factor was found, so the grace period might not be necessary in this case[/QUOTE]
[QUOTE=Viliam Furik;626457]If that is the case, then yes, the privilege period would not be needed.[/QUOTE] The grace period should still be there. People might be using older clients or different clients or whatever to find factors and report them. As long as a factor is reported without an accompanying PRPCF test, it should be put under a grace period 
Good to know an automatic CFPRP was introduced. That poaching happened to me as well  at that time I thought it was just that Primenet had handed it out quickly  so since then I was always submitting ECM results manually.
Has it ever been clarified though that the factor will only be submitted by the client once the accompanying PRP test is done? 
James asked for clarification regarding this in [URL="http://mersenneforum.org/showpost.php?p=626522&postcount=211"]another thread[/URL].

P1 found a factor in stage #1, B1=527000.
UID: Jwb52z/Clay, M117294347 has a factor: 2438434718714145482650897 (P1, B1=527000) 81.012 bits. 
[QUOTE=axn;626481]The grace period should still be there. People might be using older clients or different clients or whatever to find factors and report them. As long as a factor is reported without an accompanying PRPCF test, it should be put under a grace period[/QUOTE]
Oh, right, of course, forgot about that obvious fact... Never mind that mistaken statement of mine. It is still necessary based on all I have said before and what you said here. All good. Thanks! :tu: 
P1 found a factor in stage #1, B1=527000.
UID: Jwb52z/Clay, M117364817 has a factor: 3139092454202223433912993 (P1, B1=527000) 81.377 bits. 
[Sat Mar 18 06:11:40 2023]
UID: Magallan3s/, M333333493 has a factor: 1574509834573622837160761 [TF:80:81:mfakto 0.15pre7MGW cl_barrett32_87_gs_8] [Sat Mar 18 08:01:38 2023] found 1 factor for M333333493 from 2^80 to 2^81 [mfakto 0.15pre7MGW cl_barrett32_87_gs_8] Found a factor using MFACTO on a Radeon VII. Saved me the trouble of PRP testing that exponent :smile: 
[QUOTE=Magellan3s;627017][Sat Mar 18 06:11:40 2023]
UID: Magallan3s/, M333333493 has a factor: 1574509834573622837160761 [TF:80:81:mfakto 0.15pre7MGW cl_barrett32_87_gs_8] [Sat Mar 18 08:01:38 2023] found 1 factor for M333333493 from 2^80 to 2^81 [mfakto 0.15pre7MGW cl_barrett32_87_gs_8] Found a factor using MFACTO on a Radeon VII. Saved me the trouble of PRP testing that exponent :smile:[/QUOTE] Why skip TF 2^79 to 2^80 ? 
DC avoided, and with a ~106. bit factor found:
[url]https://www.mersenne.org/report_exponent/?exp_lo=106971629&full=1[/url] 
[QUOTE=LordJulius;627100]Why skip TF 2^79 to 2^80 ?[/QUOTE]He probably did it, but since it now shows up as a [URL="https://www.mersenne.ca/tfgaps.php"]TF gap[/URL] I redid it:
[c]no factor for M333333493 from 2^79 to 2^80 [mfaktc 0.21 barrett87_mul32_gs] tf(): total time spent: 44m 8.503s[/c] [QUOTE=kriesel;627101]DC avoided, and with a ~106. bit factor found[/QUOTE]Or, [URL="https://www.mersenne.ca/json2bbcode.php"]formatted[/URL]:[quote][M]M106971629[/M] has a 105.971bit (32digit) factor: [url=https://www.mersenne.ca/M106971629]79534574109359138908214691895351[/url] (P1,B1=582000,B2=190186920) k = 3^2 * 5^2 * 7 * 233 * 953 * 1901 * 4643 * 120433463[/quote] 
P1 found a factor in stage #2, B1=501000, B2=16987500.
UID: Jwb52z/Clay, M117383251 has a factor: 4607805263510756479738961 (P1, B1=501000, B2=16987500) 81.930 bits. 
I found 4 factors: sixth (254707775084069984279  67.8 bits); seventh (1026695470153012861417  69.8 bits); eighth (8651909121526379308519  72.9 bits) and ninth (29616184428737548369319  74.6 bits) for [URL="https://www.mersenne.ca/exponent/662869847 "]M662869847[/URL]

[QUOTE=Miszka;627135]I found 4 factors[/QUOTE]Nice! The smallest one would've been found in a few weeks by TJAOI, but you got there first.
Outside GIMPS range, but I recently found 3 factors for M[ca]4267897171[/ca] within 0.85 bits of each other: 73.915bit M4267897171 has a factor: 17807676876562259133311 74.723bit M4267897171 has a factor: 31174335411508659346271 74.765bit M4267897171 has a factor: 32092274269846547707271 
Magellan3s has again created a TF gap, twice, at M333332983. I think he needs to be more careful about something though I can't say what his specific issues are.

All times are UTC. The time now is 00:59. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2023, Jelsoft Enterprises Ltd.