Found a factor? Post it here.
M77224867 as a factor; 39977700267067630681
(this is my first find) 
Any result beats nothing...
[QUOTE=firejuggler;231558]M77224867 as a factor; 39977700267067630681
(this is my first find)[/QUOTE] M74598451 has a factor: 503061816963520412903 I know how you feel. After my first two months of "No Factor Found" and "M4xxxxxxxx is not prime", I was thrilled to get my first "success" by finding a factor. Then nothing for another month, followed by 5 in one week. 
M90283087 has a factor: 2751173282304003942331209643538752923223 :big grin:

2751173282304003942331209643538752923223 = 38558349368410981273 x 71350909138188087151

My latest factors by P1 & TF:
M3060583 has a factor: 1691625283125322626439 M4494167 has a factor: 4090602041154466841 
My computer found the following results:
M120247 has a factor: 3250729890896242123679136285673 M200699 has a factor: 2560666376539295663544430207 M200723 has a factor: 88198734084915533896490498039 M244399 has a factor: 83084225896273645625002009 M253367 has a factor: 428118424378877527039271 M332273 has a factor: 32421566974480515508133113 M334177 has a factor: 699159963919259251767503 M334297 has a factor: 776286699004616614664844151 M334331 has a factor: 531598022680052134178237519 M334421 has a factor: 881767740830242233411702927457 M335953 has a factor: 300256724398460836714288247 M666269 has a factor: 599492540010920523991 M999631 has a factor: 182642107636183257011857 I think that at this time there are no more prime factors with less than 64 bits of unfactored Mersenne numbers with the exponent in the range 0  1M. 
[QUOTE=ckdo;231582]M90283087 has a factor: 2751173282304003942331209643538752923223 :big grin:[/QUOTE]Aww, you beat my largest factor...
M52884527 has a factor: 2627817767922406323172685733372671873 Mine is from P1. I have two P1 factors (this being the larger) and a handful of TF, of course none as large as these. I didn't realize P1 work was being done up in the M90XXXXXX range; all of my work has been assigned by Primenet thus far. I'm considering branching out into LMH/etc but for now, sticking with the assignments I get. 
The following exponents have the indicated 58 bit factors:
[code]M( 3321933281 )C: 247169243036792441 M( 3321941023 )C: 257335941907083329 M( 3321941533 )C: 207520199336703217 M( 3321946711 )C: 173831252702387009 M( 3321947353 )C: 211195002096122687 M( 3321947791 )C: 192945856601239487 M( 3321952147 )C: 207085766384122673 M( 3321956731 )C: 284053769851732609 M( 3321958399 )C: 265055977878815729 M( 3321961451 )C: 265406974016828759 M( 3321964949 )C: 173958707488043393 M( 3321968057 )C: 234572555796081983 M( 3321968747 )C: 174438837843717961 M( 3321968813 )C: 162031473823121369 M( 3321970529 )C: 152471776764277769 M( 3321970957 )C: 158899298626885967 M( 3321971503 )C: 171795762921588007 M( 3321971773 )C: 220839634071945041 M( 3321973117 )C: 174763311823447463 M( 3321976067 )C: 151279820244576103 M( 3321979051 )C: 184733188755140279 M( 3321979807 )C: 191218393131095833 M( 3321980647 )C: 202327417168800727 M( 3321982369 )C: 176546613477245503 M( 3321987131 )C: 224007146605813033 M( 3321988843 )C: 228460833239381959 M( 3321989947 )C: 217502541334200791 M( 3321990323 )C: 169528687168781273 M( 3321991681 )C: 203087935003009591 M( 3321992761 )C: 228369329317261481 M( 3321992809 )C: 220645639540210559 M( 3321994223 )C: 246531602737680391 M( 3321997027 )C: 241807984207490543 M( 3321998689 )C: 170234620254279583 M( 3321999797 )C: 203984361226970543 M( 3321999929 )C: 217315342439391439 [/code] 
M433494449 has a factor: 3656480526134520654607

ECM Factor found
M5308217 has a factor: 19389284433827290601

Funny example;
M2371703 has a factor: 172106762886153056494817 The funny part is that k= 2*2*2*2*1049*1811*34469*34631, so 2kp+1 could have been found with B2= 34631 
[QUOTE=lorgix;233143]Funny example;
M2371703 has a factor: 172106762886153056494817 The funny part is that k= 2*2*2*2*1049*1811*34469*34631, so 2kp+1 could have been found with B2= 34631[/QUOTE] Even faster with B1=34631 and no stage 2. This 78 bit prime factor can be found in ~95 seconds on one core of a modern CPU. Pretty incredible. :smile: 
[QUOTE=MiniGeek;233151]Even faster with B1=34631 and no stage 2. This 78 bit prime factor can be found in ~95 seconds on one core of a modern CPU. Pretty incredible. :smile:[/QUOTE]
Yes, didn't think it through. I'm doing a large number of P1 in that exponent area with B1~ double the above, and no stage 2. Might add on stage 2 later. But as low as the limits are on some exponents in the area I think this might be a fairly effective approach. On the other end we have M234473 with its [SIZE=3]2kp+1=[/SIZE][SIZE=2][SIZE=3]750020570278149061867959407 k= 41*234,473*161,503,549*241,537,413,779 Good luck finding that with P1! :big grin: Would be nice to hear other more or less extreme examples, maybe that has/deserves a thread of its own. [/SIZE][/SIZE] 
My smallest factor yet;
M2428781 has a factor: 5404906126626057367 k=3*7*89*7583*78509 Evaded previous TF by 1.2bits. Another one; M2428661 has a factor: 1082894272153874474993 k=2*2*2*13553*22307*92177 
More cases where the largest prime factor of k is relatively small:
M[B]2430457[/B] has a factor: 113034265381620576607487  77bit k= 17*541*4987*14303*[B]35447[/B] M[B]4538137[/B] has a factor: 326333958725131675555063  79bit k= 3*7*109*15271*20509*[B]50153[/B] Is my intuition right, or are cases like these actually quite common? 
<silverman> Read my paper with Wagstaff.</silverman>.

Hi,
[QUOTE=lorgix;233295]Is my intuition right, or are cases like these actually quite common?[/QUOTE] I think so, some of "my" P1 factors, sorted by factor size: M49915309 has a factor: 2085962683046854861393 (70.82 Bits; k = 20895019231944 = 2 * 2 * 2 * 3 * 11 * 13 * 37 * 227 * 347 * [B]2089[/B]) M50739071 has a factor: 10474816683392115991831 (73.14 Bits; k = 103222393285365 = 3 * 3 * 5 * 19 * 181 * 227 * 769 * [B]3821[/B]) M51027377 has a factor: 77850684812475802805663 (76.04 Bits; k = 762832516479103 = 7 * 17 * 139 * 191 * 239 * 257 * [B]3931[/B]) M51679921 has a factor: 451068222670482355938121 (78.57 Bits; k = 4364056812997860 = 2 * 2 * 3 * 5 * 11 * 307 * 953 * 2957 * [B]7643[/B]) M53196851 has a factor: 129375114189794147350126111 (86.74 Bits; k = 1216003501690298805 = 3 * 5 * 11 * 17 * 71 * 79 * 2113 * 3571 * [B]10243[/B]) M51007903 has a factor: 416373044176966390884620641 (88.42 Bits; k = 4081456202747311440 = 2 * 2 * 2 * 2 * 3 * 3 * 3 * 5 * 13 * 59 * 89 * 563 * 4441 * [B]11071[/B]) M51094921 has a factor: 620135167283167713317314151 (89.00 Bits; k = 6068461944418778075 = 5 * 5 * 271 * 2851 * 3371 * 8429 * [B]11057[/B]) M51139447 has a factor: 1873562419055481575542379948831 (100.56 Bits; k = 18318172457510946251945 = 5 * 7 * 19 * 23 * 73 * 359 * 18457 * 35597 * [B]69557[/B]) Oliver 
But notice the latest factors my computer found using ECM:
M400087 has a factor: 286218557414155282359049 (k = 2 ^ 2 x 3 x 41737 x [B]714185251333[/B]) M400277 has a factor: 2081610233687632912124807 (k = 11 x 107 x [B]2209186189633807[/B]) These factors could not have been discovered using P1. 
[QUOTE=TheJudger;233535]Hi,
I think so, some of "my" P1 factors, sorted by factor size: M49915309 has a factor: 2085962683046854861393 (70.82 Bits; k = 20895019231944 = 2 * 2 * 2 * 3 * 11 * 13 * 37 * 227 * 347 * [B]2089[/B]) M50739071 has a factor: 10474816683392115991831 (73.14 Bits; k = 103222393285365 = 3 * 3 * 5 * 19 * 181 * 227 * 769 * [B]3821[/B]) M51027377 has a factor: 77850684812475802805663 (76.04 Bits; k = 762832516479103 = 7 * 17 * 139 * 191 * 239 * 257 * [B]3931[/B]) M51679921 has a factor: 451068222670482355938121 (78.57 Bits; k = 4364056812997860 = 2 * 2 * 3 * 5 * 11 * 307 * 953 * 2957 * [B]7643[/B]) M53196851 has a factor: 129375114189794147350126111 (86.74 Bits; k = 1216003501690298805 = 3 * 5 * 11 * 17 * 71 * 79 * 2113 * 3571 * [B]10243[/B]) M51007903 has a factor: 416373044176966390884620641 (88.42 Bits; k = 4081456202747311440 = 2 * 2 * 2 * 2 * 3 * 3 * 3 * 5 * 13 * 59 * 89 * 563 * 4441 * [B]11071[/B]) M51094921 has a factor: 620135167283167713317314151 (89.00 Bits; k = 6068461944418778075 = 5 * 5 * 271 * 2851 * 3371 * 8429 * [B]11057[/B]) M51139447 has a factor: 1873562419055481575542379948831 (100.56 Bits; k = 18318172457510946251945 = 5 * 7 * 19 * 23 * 73 * 359 * 18457 * 35597 * [B]69557[/B]) Oliver[/QUOTE] [QUOTE=alpertron;233537]But notice the latest factors my computer found using ECM: M400087 has a factor: 286218557414155282359049 (k = 2 ^ 2 x 3 x 41737 x [B]714185251333[/B]) M400277 has a factor: 2081610233687632912124807 (k = 11 x 107 x [B]2209186189633807[/B]) These factors could not have been discovered using P1.[/QUOTE] Yes, both extremes exist. But I'm curious about how common cases like these are. A 3D (exponent size, number of factors of k, sizes of factors of k) graph or a distribution table would be extremely nice. But I doubt that's at hand. Any thought or info/ideas? 
not found by me but still
M52000043 has a factor : 104000087 (k=2) thats an extreme... 
[QUOTE=firejuggler;233541]not found by me but still
M52000043 has a factor : 104000087 (k=2) thats an extreme...[/QUOTE] Yeah, I've seen a few of those... Not that big before though. A little sample; these should be the known ones in the range. M33623 has 67247 M34283 has 68567 M34319 has 68639 M34439 has 68879 M34631 has 69263 M34883 has 69767 M35099 has 70199 M35111 has 70223 M35291 has 70583 M35831 has 71663 M35999 has 71999 And it goes on.... I think it's safe to say that k=2 is common for small p. But just [I]how[/I] does the distribution look? I kinda feel like this info should be available [I]somewhere[/I]. P.S. Smallest p for which k=2 11, 23, 83, 131, 179, 191, 239, 251, 359, 419, 431, 443 After looking those up manually I realize that this is [URL="http://www.research.att.com/%7Enjas/sequences/A002515"]A002515.[/URL] 
These "k=2" you are talking about are really k=1. Factors are of the form 2kp+1. In other words, they're mp+1, with m always even. With these factors, m=2 and k=1, since the factor is equal to 2*p+1.
I'd bet that the factors of the k's break down, on average, like the factors of any natural number of about their size. And that the chance of any given k producing a factor is related to the equation given at [url]http://www.mersenne.org/various/math.php[/url]: "(how_far_factored1) / (exponent times [URL="http://www.utm.edu/research/primes/glossary/Gamma.html"]Euler's constant[/URL] (0.577...))". I don't know what that means precisely as far as how many k's will be smooth to suchandsuch bounds, but the GIMPS Math page says "The chance of finding a factor and the factoring cost both vary with different B1 and B2 values. Dickman's function (see Knuth's Art of Computer Programming Vol. 2) is used to determine the probability of finding a factor, that is k is B1smooth or B1smooth with just one factor between B1 and B2. The program tries many values of B1 and if there is sufficient available memory several values of B2, selecting the B1 and B2 values that maximize the formula above." 
[QUOTE=MiniGeek;233559]These "k=2" you are talking about are really k=1. Factors are of the form 2kp+1. In other words, they're mp+1, with m always even. With these factors, m=2 and k=1, since the factor is equal to 2*p+1.
I'd bet that the factors of the k's break down, on average, like the factors of any natural number of about their size. And that the chance of any given k producing a factor is related to the equation given at [URL]http://www.mersenne.org/various/math.php[/URL]: "(how_far_factored1) / (exponent times [URL="http://www.utm.edu/research/primes/glossary/Gamma.html"]Euler's constant[/URL] (0.577...))". I don't know what that means precisely as far as how many k's will be smooth to suchandsuch bounds, but the GIMPS Math page says "The chance of finding a factor and the factoring cost both vary with different B1 and B2 values. Dickman's function (see Knuth's Art of Computer Programming Vol. 2) is used to determine the probability of finding a factor, that is k is B1smooth or B1smooth with just one factor between B1 and B2. The program tries many values of B1 and if there is sufficient available memory several values of B2, selecting the B1 and B2 values that maximize the formula above."[/QUOTE] I'll admit to this embarrassing mistake. [B]1=/=2 [/B] Next you are touching on some very interesting stuff. Some people might remember me and at least one other person on this forum asking about the precise algorithm for determining optimal bounds given certain conditions. I have no reason to doubt that they break down essentially the same way, but it would be nice to see it, or have proof. I should follow up on those references, and hope I know enough math to wrap my head around it. I love natural constants btw; memorized Pi to 1k decimal places... For Euler's I only know ~0.577215664901... which happens to be close to 3^0.5. 
Sweet, someone finished M937 less than 24hrs ago, by finding the factor:
[B]46654722984595033623595915319018639089714063407438899506169 195bit monster. [/B] 
It appears that you did not read [url]http://www.mersenne.org/report_factors/?exp_lo=919&exp_hi=&exp_date=&fac_len=&dispdate=1&B1=Get+Factors[/url] . The 135digit prime number that completes the factorization of M919 is not shown there.

[QUOTE=alpertron;233871]It appears that you did not read [URL]http://www.mersenne.org/report_factors/?exp_lo=919&exp_hi=&exp_date=&fac_len=&dispdate=1&B1=Get+Factors[/URL] . The 135digit prime number that completes the factorization of M919 is not shown there.[/QUOTE]
I don't understand what you mean... The second largest prime factor of M937 was found yesterday. The largest prime factor is a 154digit number. M919 is also fully factored, I don't know when that happened. But that's nice too. :smile: 
The factor of M937 was not found by Primenet. I added it manually after copying it from [url]http://www.mersenneforum.org/showpost.php?p=233695&postcount=74[/url] . The huge prime factor of M919 was found by Batalov and Dodson using the SNFS algorithm while the factor of M937 was found by Bos, Kleinjung, Lenstra and Montgomery using the ECM algorithm. This information was taken from the Cunningham project.

[QUOTE=alpertron;233886]The factor of M937 was not found by Primenet. I added it manually after copying it from [URL]http://www.mersenneforum.org/showpost.php?p=233695&postcount=74[/URL] . The huge prime factor of M919 was found by Batalov and Dodson using the SNFS algorithm while the factor of M937 was found by Bos, Kleinjung, Lenstra and Montgomery using the ECM algorithm. This information was taken from the Cunningham project.[/QUOTE]
Ok, so the time I saw on PrimeNet was the time you added the factor. Congratulations to everyone who cares, and particularly the few who went the extra miles to find the factors! :smile: 
found a 'second' factor, this time for M77224373, [SIZE=2]45'192'357'913'710'021'991[/SIZE]

M332207539 has a factor: 1078409779123917134183 (found that one about 20 months ago.)
M53256451 has a factor: 1369868342874346481711 (a P1 catch from this weekend) 
M2223187 has a factor: 99607667506275209464609
77bit k=2*2*2*2*3*101*4759*26717*36343 
M3087479 has a factor: 69499497293731448560038350569
96bit k=2*2*3*1783*5501*8273*47777*241931 P1, 5hrs ago. 
M23355961 has a factor: 25246628074910152142119
k = 3^3 × 29^2 × 449 × 53011433 That was found by [I]trial factoring[/I]. I guess the k value is about 171 times greater than the default GIMPS limit (at least when that number was first trial factored; according to the current bounds it's 684 times). So is that some kind of a record k value for trial factoring!? I was testing out mprime's ability to trial factor past the default limits and wasn't expecting it to work! The thing I don't understand is that back in 2006 I ran P1 on that number with B1=1e6 and B2=1e8. It should've found that factor, right? B1 is easily large enough and B2 almost twice necessary. The machine was reliable; it returned lots of verified LLs and no known bad ones. 
Any known factor can be "found" with TF.
Hint: check the structure of the TF savefile (it is only a few bytes), check the order of modular loops (this is a bit convoluted, TF is not sequential in every bitlevel), set up the good starting values and start TF with properly prepared savefile. (Another option is to recompile Prime95 to finetune it for this task.) If the machine was reliable, then try it again; you can even save some time by using [FONT=Arial Narrow]Pminus1=1,2,23355961,1,500,60000000[/FONT] in worktodo.txt. It appears to work fine here. In that range, however, the numbers appear [URL="http://www.mersenne.org/report_exponent/?exp_lo=23355901&exp_hi=23356061&B1=Get+status"]to have been tested[/URL] to about B1=280000, B2=6370000, which is not enough to find this factor. 
[QUOTE=Batalov;238567]Any known factor can be "found" with TF. [/QUOTE]
Heh, OK. Naturally you can 'find' it with just one modular exponentiation. [QUOTE=Batalov;238567]If the machine was reliable, then try it again; you can even save some time by using [FONT=Arial Narrow]Pminus1=1,2,23355961,1,500,60000000[/FONT] in worktodo.txt. It appears to work fine here.[/QUOTE] Wait, how does that work? Won't you need 29^2<=B1 at least? I'll see if I can repeat it, but that machine's motherboard died in 2008, and I don't know for sure which version of Prime95 I used. Now here's a case where we'd like to set the stage 2 starting point... 
M2135957 has a factor: 1540376824575416172080436777449
101bit k=2^2*17*239*751*1399*6971*25033*121013 P1 
M79804321 has a [COLOR=Red]factor[/COLOR]: 50705092580156382209
recent result from me, found [SIZE=2]at December, 8th 2010[/SIZE] 
Still hanging around with Miss February, are we? :big grin:

[QUOTE=ckdo;240974]Still hanging around with Miss February, are we? :big grin:[/QUOTE]
No, Miss February should have been this one: [SIZE=2]45980579 [/SIZE][SIZE=2]FPM1 [/SIZE][SIZE=2]20100126: 56[/SIZE][SIZE=2]670576085183271870247[/SIZE] 
Add 2 more ECM factors to the list:
2 ECM factors found a day apart, after 2 months of unsuccessful attempts
M5457773 121234416604163371249241 M5456387 168049675942742879743 
Here are some of my recent finds, all found with P1:
M5568817 has a factor: 2580875798900949823169201 M5575387 has a factor: 24002502239318494727833 M5576897 has a factor: 2685038897114218470311471 M5579477 has a factor: 264051970555252442377 M5976967 has a factor: 200673846075753516727 M5975051 has a factor: 21173271365286672676124929 M5910731 has a factor: 41919405374519888959 
[QUOTE=harlee;241438]Here are some of my recent finds, all found with P1:
M5568817 has a factor: 2580875798900949823169201 M5575387 has a factor: 24002502239318494727833 M5576897 has a factor: 2685038897114218470311471 M5579477 has a factor: 264051970555252442377 M5976967 has a factor: 200673846075753516727 M5975051 has a factor: 21173271365286672676124929 M5910731 has a factor: 41919405374519888959[/QUOTE]Interesting you are in Odenton, I am in Annapolis. Lovely weather we have today, huh? How does one perform P1 on such "small" numbers? Is there an option, is it done by manual assignment, or do you simply select arbitrary numbers? (It is still amusing to me to consider a number like M5568817 to be small.) 
KinkKurly,
The weather has been so lovely, I've been inside all day except I just had to pick up my son from work. At least it too warm to snow.... Ooooops, having flashbacks to last Feb. As for the assigments, I do a "Factoring limits" query the based on the exponent range, pick the ones with small B1 & B2 bounds, created a worktodo.txt and then register them via the server. Been doing this off and on for over a year now. 
[QUOTE=harlee;241511]As for the assigments, I do a "Factoring limits" query the based on the exponent range, pick the ones with small B1 & B2 bounds, created a worktodo.txt and then register them via the server. Been doing this off and on for over a year now.[/QUOTE]harlee,
Your brief explanation assumes that the reader knows how to avoid interfering with others' assignments. Please, instead, refer folks to this LMH sticky thread: "[B]How to LMH using Prime95 v25.8 and PrimeNet v5[/B]" at [URL]http://mersenneforum.org/showthread.php?t=11308[/URL] and emphasize the importance of step 8. [QUOTE=KingKurly;241505]How does one perform P1 on such "small" numbers? Is there an option, is it done by manual assignment, or do you simply select arbitrary numbers? (It is still amusing to me to consider a number like M5568817 to be small.)[/QUOTE]KingKurly, Please see this LMH sticky thread: "[B]How to LMH using Prime95 v25.8 and PrimeNet v5[/B]" at [URL]http://mersenneforum.org/showthread.php?t=11308[/URL] It explains how to obtain assignments outside the standard PrimeNet process, [I]while making sure there's no interference or poaching[/I]. [U]Do not skip step 8 of Uncwilly's procedure  it is crucial to preventing accidental overlapping with other people's assignments[/U]! But do use the standard manual PrimeNet assignment system for exponents in ranges PrimeNet is allowing to be handed out. IOW, first try to get manual assignment from PrimeNet for your range of interest, then if PrimeNet isn't handing out that range, release any unwanted exponents it did assign you, then go to [I]carefully[/I] follow Uncwilly's procedure. 
[URL="http://www.mersenne.org/report_LL/?exp_lo=39512171&dispdate=1&B1=Get+LL+data"]M39512171[/URL] has a factor: [SIZE=2]23887910757239756825399[/SIZE]
k = 2039*71597*2070643 
M90012887 has a factor: [SIZE=2]439952565941844992833877634700202506740401 :piggie:
k1 = 3*3*5*7*11*19*52177399 k2 = 5*11*71851282747 [/SIZE] 
[QUOTE=ckdo;245560]M90012887 has a factor: [SIZE=2]439952565941844992833877634700202506740401 :piggie:
k1 = 3*3*5*7*11*19*52177399 k2 = 5*11*71851282747 [/SIZE][/QUOTE] Goodness, that's a large factor. P1, I presume? 
[QUOTE=KingKurly;245565]Goodness, that's a large factor. P1, I presume?[/QUOTE]
TF. First dual 70 bit factors I've seen for an exponent. :coffee: 
[QUOTE=ckdo;245576]TF. First dual 70 bit factors I've seen for an exponent. :coffee:[/QUOTE]
I didn't know that was possible. 
[QUOTE=lorgix;245928]I didn't know that was possible.[/QUOTE]
Why not? There's no reason a number can't have two factors that happen to have the same bit length. There's probably about a 1/4900 (70^(2)) chance that any particular Mersenne number has two factors that are 70 bits long, so it should be rare, but it's possible. 
[QUOTE=MiniGeek;245936]Why not? There's no reason a number can't have two factors that happen to have the same bit length. There's probably about a 1/4900 (70^(2)) chance that any particular Mersenne number has two factors that are 70 bits long, so it should be rare, but it's possible.[/QUOTE]
I [I]thought[/I] it would stop after finding the smaller one. I wouldn't have been surprised to see a composite factor found by P1. 
[QUOTE=MiniGeek;245936]Why not? There's no reason a number can't have two factors that happen to have the same bit length. There's probably about a 1/4900 (70^(2)) chance that any particular Mersenne number has two factors that are 70 bits long, so it should be rare, but it's possible.[/QUOTE]
Because prime95 will stop at the first found factor?! :unsure: 
[QUOTE=axn;245958]Because prime95 will stop at the first found factor?! :unsure:[/QUOTE]
Not anymore, IIRC Luigi 
Why multiply them, instead of reporting them as they are found?

[QUOTE=ET_;245974]Not anymore, IIRC
Luigi[/QUOTE] Huh? It used to be that, once upon a time, p95 used to go ahead with TF even if a factor was found, just to make sure that no _smaller_ factor was missed. Then, that was removed. You mean to say that this (mis)feature has been reintroduced?! 
[QUOTE=axn;245984]Huh? It used to be that, once upon a time, p95 used to go ahead with TF even if a factor was found, just to make sure that no _smaller_ factor was missed. Then, that was removed. You mean to say that this (mis)feature has been reintroduced?![/QUOTE]
I'm afraid I followed the wrong chain of answers. The old behavior was removed. The actual Prime95 should finish its bit range even if a factor is found. Luigi 
Which raises my question, again.
Why multiply them? Isn't that sort of the opposite of what we're trying to do here? 
[QUOTE=alpertron;231757]My computer found the following results:
M120247 has a factor: 3250729890896242123679136285673 [/QUOTE] Some work effort quantification trivia complements of: [url]http://mersennearies.sili.net/credit.php?worktype=TF&exponent=120247&f_exponent=&b1=&b2=&numcurves=&factor=&frombits=1&tobits=102&submitbutton=Calculate[/url] Finding the same factor via TF would take over 8.5 quadrillion GhzDays :shock: 
[QUOTE=lorgix;246091]Which raises my question, again.
Why multiply them?[/QUOTE]Exactly which ones are you referring to, and which procedure found them? Perhaps there's some mixup. TF doesn't multiply them. (I've seen TF report two found factors from a single run; it did so on separate "has a factor" lines, not presented as the product of the two.) P1, by its nature, may find the product of two smaller factors at the conclusion of its GCD, rather than finding the two separately. Isn't that the method involved in the case you reference? [quote]Isn't that sort of the opposite of what we're trying to do here?[/quote]:smile: 
[QUOTE=cheesehead;246180]Exactly which ones are you referring to, and which procedure found them? Perhaps there's some mixup.[/QUOTE]
Post #46. [QUOTE]TF doesn't multiply them. (I've seen TF report two found factors from a single run; it did so on separate "has a factor" lines, not presented as the product of the two.)[/QUOTE]That's what I'd expect. Hence the question; why multiply? [QUOTE]P1, by its nature, may find the product of two smaller factors at the conclusion of its GCD, rather than finding the two separately. Isn't that the method involved in the case you reference?[/QUOTE]No, as you know by now; he claims it was found by TF. In post #51 I wrote that I thought it would have stopped after finding the smaller one. But that I wouldn't at all be surprised to see that factor found by P1. 
This is my largest factor so far
52526609 has a factor: 156325851414571040867100443817329068296081239222450719 Found by P1 
That's a composite; p24*p30. Still, nice find!

[QUOTE=MiniGeek;233559]These "k=2" you are talking about are really k=1. Factors are of the form 2kp+1. In other words, they're mp+1, with m always even. With these factors, m=2 and k=1, since the factor is equal to 2*p+1.
I'd bet that the factors of the k's break down, on average, like the factors of any natural number of about their size. And that the chance of any given k producing a factor is related to the equation given at [url]http://www.mersenne.org/various/math.php[/url]: "(how_far_factored1) / (exponent times [URL="http://www.utm.edu/research/primes/glossary/Gamma.html"]Euler's constant[/URL] (0.577...))".[/QUOTE] That's probably the case for other k. However it is a [url=http://en.wikipedia.org/wiki/Sophie_Germain_prime]theorem[/url] that if p is a prime congruent to 3 (mod 4) then 2p+1 divides Mp iff 2p+1 is prime. This must affect the statistics. I'm not aware of any comparable theorem for other k. 
[QUOTE=lorgix;246322]That's a composite; p24*p30. Still, nice find![/QUOTE]
Yes. I tend to view composite factors as two factors, rather than as a big factor. Still a P30 is not to be sniffed at 
M39375727 has a factor: 13698938687421045884119517033
M42516611 has a factor: 124316222847533124840651137 The second half of last year was really poor for me. I got no factors at all between 8 August and 26 November. Then three in December, and these twoinarow this month. M39787039 has a factor: 1700513525404800279754718890351 A nice p31 found back in February last year. 
I also agree that we should view composite factors as two smaller ones. Here is my 2nd largest one, also found by P1:
M51443083 has a factor: 25320591696138535897675469195834877349466521 I'm also assuming that this is composite since it is so large. I'm still very new at this, and learning. Can you tell me what you are doing, or using to tell if these numbers are composite or not? Also, maybe I'm getting more than my share, but I've been doing P1 work for 18 months now, and I've found 24 factors in 331 tests, at about a 7.25% rate. Thanks, Doug 
[QUOTE=drh;246541]
M51443083 has a factor: 25320591696138535897675469195834877349466521 [/QUOTE] 25320591696138535897675469195834877349466521 = 857285347808257713679 x 29535780310340488803799 [QUOTE] I'm also assuming that this is composite since it is so large. I'm still very new at this, and learning. Can you tell me what you are doing, or using to tell if these numbers are composite or not? [/QUOTE] One easy way is to use [url]http://www.alpertron.com.ar/ECM.HTM[/url]. 
[QUOTE=drh;246541]Can you tell me what you are doing, or using to tell if these numbers are composite or not?[/QUOTE]
A really neat trick is to use the P+1 method with the same bounds as the original P1 test. This has a 50% chance per run of resolving the two factors, and will usually do so in a fraction of the processor time that other methods would take. [code]$ echo "25320591696138535897675469195834877349466521"  ecm c 0 pp1 60000 GMPECM 6.2 [powered by GMP 4.2.2] [P+1] Input number is 25320591696138535897675469195834877349466521 (44 digits) Using B1=60000, B2=19419970, polynomial x^1, x0=2552205880 Step 1 took 88ms Step 2 took 96ms Run 2 out of 0: Using B1=60000, B2=19419970, polynomial x^1, x0=1936717407 Step 1 took 80ms [factor found by P1] ********** Factor found in step 2: 857285347808257713679 Found probable prime factor of 21 digits: 857285347808257713679 Probable prime cofactor 29535780310340488803799 has 23 digits $[/code] Not that other methods take much processor time, but I think this is a neat 'hack'. 
Just wanted to thank lorgix, Mr. P1, and rajula for responding, and getting me started down the path of understanding, as I'm not a mathematician. I'm sure I'll have lots more questions.
Doug 
[QUOTE=drh;246541]Can you tell me what you are doing, or using to tell if these numbers are composite or not?[/QUOTE]
A simple heuristic is, if its size is more than double the TF limits, then it's almost certainly composite. P1 (to the limits chosen by Prime95) rarely finds prime factors much more than about 100 bits, and rarely finds composite factors less than double the TF limits (since this would imply a missed TFsized factor.) The quickest way to [i]prove[/i] these numbers composite would be a PrP test, which wouldn't tell us the prime factors. In practice, we don't bother, because we're interested in the prime factors anyway, and factoring them is so easy. Theoretically, if a large P1 factor should resist factorisation for any length of time, we might begin to suspect it to be prime after all. To prove a number of that size prime, I'd use Pari/GP's isprime() function. There are several other tools capable of proving much larger numbers prime. 
Another find thanks to Suyama's extension;
P1 found a factor in stage #2, B1=85000, B2=[B]1742500[/B]. M2294807 has a factor: 4743377217925125644071 k= 3^3*5*751*3851*[B]2647063[/B]  You're welcome drh! I'm learning too, heck we all are. I usually use [URL]http://factordb.com/[/URL], that site stores the factor as well. But all the other suggestions are great too. 
[QUOTE=lorgix;246956]Another find thanks to Suyama's extension;[/QUOTE]
E? 
Actually the output doesn't say.
But it always uses E=6 under similar (to the ones in question) circumstances. 
From TF 
M80307593 has a factor: 144625571114343550097 
[QUOTE=lorgix;247036]Actually the output doesn't say.
But it always uses E=6 under similar (to the ones in question) circumstances.[/QUOTE] That's curious. Normally it give the E value in the result.txt file, if it's higher than 2. How many relative primes out of how many were you able to do per pass? 
All 480 in one pass. 498MB.
I used to think the same. But it appears to me now that it doesn't do that if a factor is found. More recent find below, where Suyama's extension wasn't needed. Still used E=6, but doesn't show it here for some reason. P1 found a factor in stage #2, B1=90000, B2=1755000. M2299571 has a factor: 103653914718894079697 
Close or what?
P1 found a factor in stage #2, B1=95000, B2=[B]1947500[/B]. M2444359 has a factor: 1588994437060952149274017 k= 2^4*3*31*41*197*13901*[B]1945487[/B] 
From P1:
M1983503 has a factor: [SIZE=2]186794246935371583225132033 Does anyone have recommendations for other places to run P1? I did a bunch of M1983xxx to celebrate my recent birthday, which may have been in 1983. I have plenty of cores dedicated to "normal" P1 (which is mostly in the 53M range right now), but I'm interested in running P1 in other ranges too. [/SIZE] 
From the point of view of project progress (defining progress as moving forward the leading edge of firsttime LL tests), the type of P1 you are doing (53M range) is the most appropriate, specially if you are using considerable amounts of memory. Therefore, from [U]that[/U] POV, that is my recommendation.
But of course, as repeated [I]ad nauseam[/I] by many forumites (including myself), it´s your machine, so do as you like it the most and enjoy the participation. Every bit counts! 
Understood; I still have several cores dedicated to 'mainline' P1 (53M range), and I am using considerable amounts of memory on my main machine... about 6GB dedicated to mprime with two cores running that sort of P1. Then recently I've had a third core running "small" P1. I found a few more factors in M1983xxx and decided to start poking through M1982xxx and M1984xxx. Not sure where I'll head from there, but it seems like I'm finding a lot of exponents in the small ranges that have never had stage 2 of P1. Looks like the stuff under 1M has mostly been done, but there were a bunch I saw between 1M and 2M. It looks like we are assigning ECM curves when the exponent has not had a "proper" P1, am I missing something there?
I do understand that finding factors to smaller Mersenne exponents will not help find the next Mersenne prime. Fortunately for the project, I also have several cores dedicated to "real P1", LLD, and LL. Heck, I even have a few smaller cores running TF, and even a bit of ECM. (And yes, I understand that ECM finds factors to small Mersenne exponents, which like my 'small P1' pursuit, does not help find the next prime.) You are right, they are my machines, and I like what I'm doing. :) I just thought it'd be fun to have one core working on "exploratory" work, although perhaps that isn't the right word. Nonstandard work? I don't know. I did notice a bunch of exponents below 1M that have P1 bounds with B1=B2=exponent. For example M909107 has P1 bounds of 909107. Was that value as arbitrarily selected as the B1=1M, B2=30M that I've been using? Sorry for the jumbled streamofconsciousness style of this post. 
A suggestion is to do some work on the 332M range.
That´s where the 100M digit numbers start, and there are a few people working on that range, mainly doing TF, but also some P1 (and even LL tests!...). As you said you would like to do some "exploratory" work, you might enjoy joining. A generous amount of memory is recommended for numbers this big. You may wish to have a look at this thread: [URL]http://www.mersenneforum.org/showthread.php?t=10693[/URL] 
[QUOTE=lycorn;248090]A suggestion is to do some work on the 332M range.
That´s where the 100M digit numbers start, and there are a few people working on that range, mainly doing TF, but also some P1 (and even LL tests!...).[/QUOTE]There are currently 18 available for P1 in the 332M range. And from 332400000 to 332999999 is all essentially at 67 bits. There are tons of factors out there. (From 332192831 (the lowest 100M digit) to 332399999 is at 70 or better). 
[QUOTE=Uncwilly;248101]There are currently 18 available for P1 in the 332M range. And from 332400000 to 332999999 is all essentially at 67 bits. There are tons of factors out there. (From 332192831 (the lowest 100M digit) to 332399999 is at 70 or better).[/QUOTE]
I've started a P1 of M332205149, it's using an 18M FFT and "up to 6144MB" of memory, B1 of 3365000, B2 of 95902500, and currently estimated to complete in early May or thereabouts. Now I've got high (332M), medium (53M), any suggestions for low? I notice there are 60k+ factored exponents below 1M, how can I help advance that number? (I wonder if I will live to see the day that they all have at least one factor?) Or if sub1M exponents are pretty well covered, maybe sub10M? I've been finding more factors in the 1982xxx1984xxx area by manually adding Pminus1 lines. Though doing Pminus1 makes me nervous a bit because I don't seem to get assignment IDs for them; I certainly don't want to be stepping on any toes. Doing Pfactor and/or using the manual assignment form seems to work okay, but only if Primenet believes it needs further P1. Using Pfactor for a low exponent seems to use pretty wimpy B1/B2, so I have specified some beefier values in a Pminus1 line. ...What am I doing, it's a Friday night and I'm playing with Mersenne numbers. Hoo boy... :P 
[QUOTE=KingKurly;248154]Using Pfactor for a low exponent seems to use pretty wimpy B1/B2, so I have specified some beefier values in a Pminus1 line.[/QUOTE]
[code] Pfactor=...,1,2,8323009,1,64,[COLOR=Red][B]10[/B][/COLOR] [/code]gives me [code] [Worker #2 Jan 22 11:19] Optimal P1 factoring of M8323009 using up to 3560MB of memory. [Worker #2 Jan 22 11:19] Assuming no factors below 2^64 and 10 primality tests saved if a factor is found. [Worker #2 Jan 22 11:19] Optimal bounds are [COLOR=Red][B]B1=510000, B2=15682500[/B][/COLOR] [Worker #2 Jan 22 11:19] Chance of finding a factor is an estimated 7.7% [Worker #2 Jan 22 11:19] Using Pentium4 type3 FFT length 448K, Pass1=448, Pass2=1K [/code]That's a start. 
M8401051 has a factor: 278879821834503938295782902841
k=2*2*5*11*131*113947*165541*[B]30531703[/B] B1=520000, B2=15990000, E=12 :big grin: 
[QUOTE=KingKurly;247994]It looks like we are assigning ECM curves when the exponent has not had a "proper" P1, am I missing something there?[/QUOTE]I presume that by "proper", you mean that the B1/B2 are sufficiently high to satisfy your (or someone's) sense or propriety.
Though some exponents that had only very low B1/B2 (such as 30) have had their P1 history expunged from the database, others with whatI'dconsiderinadequate B1/B2 were allowed to remain. What's the lowest B1 you see in the database in the ranges you've examined? [quote]I did notice a bunch of exponents below 1M that have P1 bounds with B1=B2=exponent. For example M909107 has P1 bounds of 909107. Was that value as arbitrarily selected as the B1=1M, B2=30M that I've been using?[/quote]If you mean, "did the prime95/mprime algorithm ever select B1=B2=exponent, such as B1=B2=909107 for M909107?" the answer is "no". Those were all specified manually by whoever ran the tests. That would be true generally for any B1/B2 that are not multiples of 5000 and 1250, respectively. [quote]Sorry for the jumbled streamofconsciousness style of this post.[/quote]Why should yours be any different? :) [QUOTE=KingKurly;248154]I've been finding more factors in the 1982xxx1984xxx area by manually adding Pminus1 lines. Though doing Pminus1 makes me nervous a bit because I don't seem to get assignment IDs for them; I certainly don't want to be stepping on any toes.[/QUOTE]Here's how to reserve them and get assignment IDs: 1. Before calling PrimeNet, substitute, or add, a Factor= line, specifying bit levels above whatever those exponents already have (you might be able instead to use Test= or any other keyword that's not for P1; I used only Factor=) for each exponent you want to P1 on. 2. Then, contact PrimeNet. PrimeNet will assign you an ID (if no one else is working on it, other than ECM, which can tolerate multiple simultaneous assignments) for each of your Factor= lines. 3. For the exponents that did not get an assignment ID, that means someone else has reserved it, so don't process those exponents now. 4. Then, copy the assignment IDs into your P1 worktodo lines and put them back into the worktodo (and remove the Factor= lines), for only the exponents for which you _did_ get an assignment ID. 5. If you don't report any of the P1 to PrimeNet until all are completed, your use of the assignment IDs for the P1 won't cause any trouble. (I don't recall whether there was any trouble when I contacted PrimeNet while I had unfinished P1s with the copied assignment IDs still in the worktodo. Maybe there wasn't then, either.) 
[QUOTE=ckdo;248223][code]
Pfactor=...,1,2,8323009,1,64,[COLOR=Red][B]10[/B][/COLOR] [/code]gives me [code] [Worker #2 Jan 22 11:19] Optimal P1 factoring of M8323009 using up to 3560MB of memory. [Worker #2 Jan 22 11:19] Assuming no factors below 2^64 and 10 primality tests saved if a factor is found. [Worker #2 Jan 22 11:19] Optimal bounds are [COLOR=Red][B]B1=510000, B2=15682500[/B][/COLOR] [Worker #2 Jan 22 11:19] Chance of finding a factor is an estimated 7.7% [Worker #2 Jan 22 11:19] Using Pentium4 type3 FFT length 448K, Pass1=448, Pass2=1K [/code]That's a start.[/QUOTE] Aha, so the trick is to trick the software/server into believing that we'll be saving more primality tests than we really are. Sounds good. :smile: 
[QUOTE=cheesehead;248531]I presume that by "proper", you mean that the B1/B2 are sufficiently high to satisfy your (or someone's) sense or propriety.
Though some exponents that had only very low B1/B2 (such as 30) have had their P1 history expunged from the database, others with whatI'dconsiderinadequate B1/B2 were allowed to remain. What's the lowest B1 you see in the database in the ranges you've examined? [/QUOTE] Yes, you are correct in your understanding of my use of the word 'proper'. I'd seen some with B1=B2=40k; I guess I can poke around the DB a little bit more and see if I find anything lower. [QUOTE=cheesehead;248531] If you mean, "did the prime95/mprime algorithm ever select B1=B2=exponent, such as B1=B2=909107 for M909107?" the answer is "no". Those were all specified manually by whoever ran the tests. That would be true generally for any B1/B2 that are not multiples of 5000 and 1250, respectively.[/QUOTE] Gotcha. [QUOTE=cheesehead;248531]Here's how to reserve them and get assignment IDs:[/QUOTE] Between your advice and ckdo's advice, I think I've got it figured out now; thanks! It looks like Pfactor lines will suffice after all, as long as I fudge the number of tests that would be saved. I was being "too truthful" and answering 0, which was autoselecting pretty low B1/B2. When doing Pminus1 lines, I wasn't using any particular formula to pick B1/B2, just using a larger value for B1 than I saw in the DB, and then B2 somewhere around 20 or 30x B1. 
Three very nearly in a row!
M2909701 has a factor: 34116886410693051247
k = 3 * 41^2 * 1913 * 607697 M2909749 has a factor: 165757446506320718519 k = 7 * 2417 * 7477 * 225157 M2909827 has a factor: 17618623784616481399 k = 3^3 * 257 * 281 * 1552643 All in P1 stage #2, B1=105000, B2=2283750, E=6. I keep thinking I should reduce the bounds... 
ECM testing in M800xxx area
After running 220 ECM curves with B1=50000 for 12 numbers in the M800xxx area I found:
M800123 has a factor: 39697452239411289096120887 M800131 has a factor: 1236262353488699154645983 M800351 has a factor: 499211152072761829658937337 M800731 has a factor: 42794895872489861161754233 
[QUOTE=alpertron;249972]After running 220 ECM curves with B1=50000 for 12 numbers in the M800xxx area I found:
M800123 has a factor: 39697452239411289096120887 M800131 has a factor: 1236262353488699154645983 M800351 has a factor: 499211152072761829658937337 M800731 has a factor: 42794895872489861161754233[/QUOTE] How'd you settle on 220 as the number of ECM curves to run? (Just curious) Normally I see 1, 3, and 150. 
You can change the [B]worktodo.txt[/B] file in order to do that. My idea was to complete the 25digit level.

[QUOTE=alpertron;249975]You can change the [B]worktodo.txt[/B] file in order to do that. My idea was to complete the 25digit level.[/QUOTE]
Ah, okay. I knew how to do it, I just wasn't sure why you had chosen 220, now I understand, thank you. In an unrelated note, I've been doing a bunch of P1 in the M198xxxx range and found some factors, if I have a chance I'll post them later. I hope to finish them ASAP because I hadn't yet figured out how to reserve exponents, but I did ensure that they weren't already reserved at the time I selected this range. I saw some people doing ECM in the M196xxxx and I hope to finish off any remaining unreserved exponents before they reach me. Now that I know how, in the future, I will ensure that all exponents are properly reserved. But I think I will be done with the unreserved ones in the next 2448 hours, so I am not going to bother getting assignment IDs for them I suppose... I just reserved M1979xxx (about 30 exponents) and will probably keep working my way around the upper portions of the 1.9M range  as I mentioned, from now on, I will be reserving exponents in advance. 
Another result in this area (5 factors from 13 numbers = 38% efficiency):
M800971 has a factor: 289524442699835508796196072489 
thanks to mfackt....
[quote] M80622803 has a factor 156127704855377865257 M80547619 has a factor 164225854090231111921 M80623813 has a factor 74358285257003853433 M80465149 has a factor 205346902306982285351 M80645441 has a factor 74037992691676741151 M80429911 has a factor 33776959888323700737 M80625551 has a factor 110687074647006079529 M80589031 has a factor 46693727088018753713 M79154843 has a factor 68788380075731936863 M80701741 has a factor 57218973166606961263 M80309303 has a factor 118578090508483702721 M80696089 has a factor 66027939754284563593 M80699447 has a factor 47032613446676890273 M80630159 has a factor 5856285027082755031 M80700929 has a factor 44381842139698978511 M80701553 has a factor 45527575148762247041 M80624041 has a factor 37515177594283365607 M80581283 has a factor 70717839619935960241 M80701561 has a factor 55672736219070980281 M80650799 has a factor 51454583621456883601 M77224867 has a factor 39977700267067630681 [/quote] in the last few days, all by TF 
TF 
M80076611 has a factor: 306028098438561259951 
I just finished with the M198xxxx range. Most of them previously had P1 with B1=B2=40000, and I did them all to B1=1000000, B2=30000000... kinda arbitrarily selected bounds, but they were fairly successful. I found 19 factors in 215 tests (8.84% success rate), with eight factors in Stage 1 and eleven factors in Stage 2.
[CODE] [FONT=Courier New, monospace]M1980023 has a factor: 13571695065543008351 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1980247 has a factor: 1028007425734913593231 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1980523 has a factor: 11068436810055540356047 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1981409 has a factor: 437425184457765488071 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1981493 has a factor: 98629747385844827351 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1982989 has a factor: 6724437055332257192401 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1983503 has a factor: 186794246935371583225132033 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1983643 has a factor: 341312694343914135923033 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1983913 has a factor: 31641965132080519849 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1984069 has a factor: 1899812306079643525511 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1985849 has a factor: 930999806671532321831 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1985887 has a factor: 243125032539991259230127 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1986199 has a factor: 2956613317747890929 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1986337 has a factor: 31682922079570461988879 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1987693 has a factor: 16044916528780756946806361 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1988669 has a factor: 4129291590996270537719 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1988887 has a factor: 5280340350328940238497 (Stage 1)[/FONT] [FONT=Courier New, monospace]M1989643 has a factor: 95213757966946302721 (Stage 2)[/FONT] [FONT=Courier New, monospace]M1989671 has a factor: 10604060702216236539257 (Stage 2)[/FONT][/CODE] 
All times are UTC. The time now is 03:02. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2023, Jelsoft Enterprises Ltd.