![]() |
UID: storm5510/7700_Kaby_Lake, M7755521 has a factor: 105137409539055148931876353 (P-1, B1=370000, B2=8140000, E=6)
86.442 bits. This is not a record here, or for me. However, it is the first I have found of any significance is a really long time. |
P-1 found a factor in stage #2, B1=760000, B2=13680000.
UID: Jwb52z/Clay, M99633031 has a factor: 97905827678596252126675363231 (P-1, B1=760000, B2=13680000), 96.305 bits. |
From [I]gpuOwl[/I]:
{"status":"F", "exponent":"7765781", "...":"PM1", "B1":"370000", "B2":"8140000", "...", "factors":["140468706376328182650630225863",...} 96.826 bits. {"status":"F", "exponent":"7766881", "...":"PM1", "B1":"370000", "B2":"8140000", "...", "factors":["14786058658810602089190892018393"...} 103.544 bits. I shortened these a little for readability. |
332283361 Factored
297034017173995954820063 77 bits The exponent has previously had a total about 60% of a first time check run (3 different users). What a waste of cycles when a factor was so close. I have done 7 different single bit factoring runs on this exponent (2009, 2012, 2014, 2014, 2015, 2017, 2020) |
If the exponent would have received proper P-1'ing with stage 2, the same factor would long have been found, even barely with the lower GPU72 bounds.
|
Some I have found in recent days:
[QUOTE]{"status":"F", "exponent":"7772591", "..."factors":["217829919898848456896764649"], "..."} 27 digits. 87.493 bits. {"status":"F", "exponent":"7773749", "..."factors":["755815062954005295953743"], "..."} 24 digits. 79.322 bits. {"status":"F", "exponent":"10037099", "..."factors":["75804608324741176071997207"], "..."} 26 digits. 85.970 bits. {"status":"F", "exponent":"10039303", "..."factors":["10264737979425392203143761"], "..."} 26 digits. 83.086 bits. {"status":"F", "exponent":"7783463", "..."factors":["1348646481756687012246977831"], "..."} 28 digits. 90.124 bits. {"status":"F", "exponent":"8028799", "..."factors":["817275039261758312823819887"], "..."} 27 digits. 89.401 bits. {"status":"F", "exponent":"8030609", "..."factors":["190035152807530410451188527"], "..."} 27 digits. 87.296 bits.[/QUOTE]JSON makes these a bit tedious to prepare. |
[QUOTE=storm5510;551210]JSON makes these a bit tedious to prepare.[/QUOTE]Does this make it simpler? Now with sortable columns for exponent/bits/date.
[url]https://www.mersenne.ca/pm1user/63934/date[/url] You can copy-paste with BBcode already provided:[quote][M]M8030609[/M] has a 87.296 bit factor: [url=https://www.mersenne.ca/M8030609]190035152807530410451188527[/url] [M]M8028799[/M] has a 89.401 bit factor: [url=https://www.mersenne.ca/M8028799]817275039261758312823819887[/url] [M]M8020049[/M] has a 73.671 bit factor: [url=https://www.mersenne.ca/M8020049]15041194718010883036649[/url] [M]M7783463[/M] has a 90.124 bit factor: [url=https://www.mersenne.ca/M7783463]1348646481756687012246977831[/url] [M]M10039303[/M] has a 83.086 bit factor: [url=https://www.mersenne.ca/M10039303]10264737979425392203143761[/url] [M]M10037099[/M] has a 85.971 bit factor: [url=https://www.mersenne.ca/M10037099]75804608324741176071997207[/url] [M]M7773749[/M] has a 79.322 bit factor: [url=https://www.mersenne.ca/M7773749]755815062954005295953743[/url] [M]M7772591[/M] has a 87.493 bit factor: [url=https://www.mersenne.ca/M7772591]217829919898848456896764649[/url][/quote] |
That's snazzy!
|
[STRIKE]Oliver[/STRIKE]Ryan must be too [STRIKE]modest[/STRIKE]busy to mention this one:
3307 has (another factor) [C]3413215452475967590824666626325289455333796024133147903[/C] 181.1 bits Found on [STRIKE]April 17[/STRIKE]July 19. The kicker is that the remaining cofactor is...... a PRP prime. Here it is in all of its 895 digits of glory [code]4353524133827611408574208775478589622111831317341613312984483361937010301205675662770047321087657048773241272664969392649718635926074520045281026910770712314524181933285227032125890659729016386069176693616914507334697422980860732777622339397522425721336605336658097363439448188753603624197638404803872825913098432275237874692169933508441748813480413682045289248409103532867732796807798694178375216208599640289769681995273685523060799468166287838493578146083048523489321729004640944722830982540726315520246334782951056660779801812979132998107387817802450037638989678012221564659671646755919013676548232993387587588481088712201127163199334146273445861473198777280904858096693010663932570520300269384917851688798854877340668001753453962945664051594771519075317923436346650061743281400127677733596528217642970792987250908618113230982353461817488308071861173968794875263418257665630917664743895435713[/code] Dario's ECM site confirms it. |
[QUOTE=Uncwilly;551258]Oliver must be too modest to mention this one: 3307 has (another factor).[/QUOTE]
That's because Ryan found it, I only appear in another result line (if you were thinking about me). :razz: |
[QUOTE=James Heinrich;551218]Does this make it simpler? Now with sortable columns for exponent/bits/date.
[URL]https://www.mersenne.ca/pm1user/63934/date[/URL] You can copy-paste with BBcode already provided:[/QUOTE] Wow! That is a lot simpler. Some of the older programs, like [I]CUDAPm1[/I] and [I]CUDALucas[/I] could migrate to JSON. On the other hand is [I]gpuOwl[/I]. It does those jobs and generates JSON. Perhaps there is no point in update the older ones after-all. [I]mfaktc[/I] would be a good candidate though. Just some ideas... |
| All times are UTC. The time now is 22:46. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.