mersenneforum.org Factoring humongous Cunningham numbers
 User Name Remember Me? Password
 Register FAQ Search Today's Posts Mark Forums Read

 2019-01-11, 19:47 #1497 Dr Sardonicus     Feb 2017 Nowhere F3A16 Posts Just out of curiosity, I tried looking at the Google caches of pages with homogeneous Cunningham factorizations. I'm not sure what the results may signify. The first one was kind of surprising. The cache of the "8+3" page was dated January 9, 2019 and had the C179 factorization. Other pages which would have the new information listed a few posts back (I only tried 4 or 5 of them), hadn't been cached since anywhere from mid-December back to mid-November 2018, and didn't have the new information. I was not able to navigate to any of the actual pages. The browser says "Contacting www.leyland.vispa.com" and just sits there. Alas, I am an absolute dolt when it comes to command-line scripts for a unix or unixalike shell. My understanding is that, unlike back in the old days, if you try to use "ping" to tell whether a site is up, you have to use the return value (NOT the output). I found short scripts on line that do this, but I don't understand the language. Last fiddled with by Dr Sardonicus on 2019-01-11 at 19:59
2019-01-11, 20:56   #1498
jyb

Aug 2005
Seattle, WA

110001111112 Posts

Quote:
 Originally Posted by Dr Sardonicus Just out of curiosity, I tried looking at the Google caches of pages with homogeneous Cunningham factorizations. I'm not sure what the results may signify. The first one was kind of surprising. The cache of the "8+3" page was dated January 9, 2019 and had the C179 factorization. Other pages which would have the new information listed a few posts back (I only tried 4 or 5 of them), hadn't been cached since anywhere from mid-December back to mid-November 2018, and didn't have the new information. I was not able to navigate to any of the actual pages. The browser says "Contacting www.leyland.vispa.com" and just sits there. Alas, I am an absolute dolt when it comes to command-line scripts for a unix or unixalike shell. My understanding is that, unlike back in the old days, if you try to use "ping" to tell whether a site is up, you have to use the return value (NOT the output). I found short scripts on line that do this, but I don't understand the language.
The site was up and responding very quickly when I tried it yesterday (or maybe it was Wednesday). Perhaps it wasn't up long enough to get more than a few pages cached.

2019-01-11, 21:00   #1499
xilman
Bamboozled!

"𒉺𒌌𒇷𒆷𒀭"
May 2003
Down not across

37×281 Posts

Quote:
 Originally Posted by jyb The site was up and responding very quickly when I tried it yesterday (or maybe it was Wednesday). Perhaps it wasn't up long enough to get more than a few pages cached.
It's still borked AFAICT.

2019-01-21, 14:02   #1500
Dr Sardonicus

Feb 2017
Nowhere

1111001110102 Posts

Quote:
 Originally Posted by jyb The following are all factors reported to me since the last update, through Dec. 26th.
The Homogeneous Cunningham numbers site is back up, and as far as I checked, had all the new data from the quoted post.

 2019-01-25, 09:49 #1501 unconnected     May 2009 Russia, Moscow 2×5×251 Posts 7-6_335 Code: prp75 = 229598680631885433367265926368682372432668526186133616419286306022691803541 prp56 = 60763052977326833156900039094453364793885836761103857491
2019-01-30, 05:09   #1502
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

106328 Posts

Quote:
 Originally Posted by VBCurtis I'm running this factorization mostly out of stubbornness at this point. I've sieved Q=13-88M, with about 163M raw relations found. Sec/rel is more than double what it was at the outset, so it'll be a couple more weeks on half a 6-core i7. I still expect to be able to compare to GNFS-170 time, but I don't expect the comparison to be favorable!
Four more weeks and only 65M more relations, for 228M total raw relations. I moved to 15e about a week ago to get yield above 1.0, but sec/rel is terrible (like .335 per core). I reached Q=147M.

I decided to try filtering on this dataset just in case octics build matrices more easily; remdups found 186M unique relations, a pleasantly low duplicate rate.
Unfortunately, msieve core dumps immediately, with no indication in the log of an error. Seems my copy of msieve doesn't like the octic poly.

So, I'm aborting this factorization. If someone would like the .dat and associated .fb .log and .poly, I can make a dummy account on a public-facing linux box and allow you to scp the files to your local establishment. I spent roughly one thread-year on sieving.

EDIT: I located a newer msieve binary, and am retrying filtering. The one I used initially was 1.52, oopsie.

If someone has advice or perhaps a newer copy of msieve that works with octics, let me know. I think I'm using a linux binary released early 2015.

Last fiddled with by VBCurtis on 2019-01-30 at 05:39

2019-01-30, 06:48   #1503
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

450610 Posts

Quote:
 Originally Posted by VBCurtis EDIT: I located a newer msieve binary, and am retrying filtering. The one I used initially was 1.52, oopsie.
...and a matrix built. Even at default density, it's not too big (7M). I'll have factors in a week or so.

2019-01-30, 18:02   #1504
jyb

Aug 2005
Seattle, WA

3×13×41 Posts

Quote:
 Originally Posted by VBCurtis ...and a matrix built. Even at default density, it's not too big (7M). I'll have factors in a week or so.
Indeed, you might have been seeing this: https://mersenneforum.org/showpost.p...9&postcount=47.

2019-01-31, 14:56   #1505
richs

"Rich"
Aug 2002
Benicia, California

1,171 Posts
7-4_313 factored

C123 cofactor of 7^313-4^313:

Code:
prp64=3400573965346466446905317578185464922150898055196834374966000621
prp60=204001669044014281969176189515388927772294672082364068743861
I started this job in December and my laptop's cooling fan failed during sieving, just hours before I departed on a 12 day trip to New York. Repairs effected after my trip and factoring was completed. Longest ever C123 job for me!

Factors reported to FDB and the Homogeneous Cunningham numbers reservation website.
Attached Files
 nfs.log (17.8 KB, 25 views)

2019-02-01, 18:09   #1506
VBCurtis

"Curtis"
Feb 2005
Riverside, CA

2·3·751 Posts

Quote:
 Originally Posted by VBCurtis 14e/31LP, -a side sieving, alim=rlim=33.5M produced output in a typical range (yield just over 2, sec/rel faster with these small lim's than with 67M on R side alone or both sides). I expect to sieve Q from 6M to ~75M. I have the job running 6-threaded on a 6-core i7 already running 5xLLR; it'll take about 3 weeks. That's roughly the time a GNFS-159 would take, so SNFS-octic-175 is about 4 times faster than GNFS on the 169-digit cofactor would be.
This octic is now complete:
Code:
p50 factor: 33975868649651970899016905571752528467879050171601
p119 factor: 65135797998562415430798528249917370000456077731320932657143758869464297497211359496770902593185380419179035841099471781
14e/32LP was barely OK with rlim and alim of 134M. I sieved Q from 13M to 147M to generate 220-something-million relations, 186M of which were unique. I was surprised to find that sufficient to build a matrix 7.5M in size at TD 80.

After learning I'd been using a very old copy of msieve, I finally figured out how to compile the current source. Using msieve-1028 with VBITS=128, this matrix solved in just 26 hours! My old 1.52 would have taken 35+ hrs.
All it took to compile was to turn zlib and ecm off; I hadn't solved how to build those in, and had previously given up on compiling msieve.

Sieving for this octic took longer than GNFS would have, by about 50% (say, the time GNFS-172 would have taken). If I'd put more time into parameter selection and test-sieving, perhaps I could have performed SNFS in about the time of GNFS-170, but that still means octics are basically useless down at this size.

2019-02-01, 23:52   #1507
VictordeHolland

"Victor de Hollander"
Aug 2011
the Netherlands

23·3·72 Posts

Becker considers me a spammer (I've removed the hyperlink so the real spammers/bots don't spam him more).

Quote:
 This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: becker at cs dot stanford dot edu SMTP error from remote mail server after end of data: 550 High probability of spam
Quote:
 Hi, 11^250+2^250 C137 cofactor factors as: P65=43384368922432254527616287170558228156414868291226196549435530001 P72=273555149284948010682683379415450663796438535036546739566725882170808501 Using CADO-NFS (GNFS) Met vriendelijke groet/ Kind Regards, Victor de Hollander

 Similar Threads Thread Thread Starter Forum Replies Last Post wpolly Factoring 26 2016-07-29 04:34 Xyzzy Cunningham Tables 42 2014-04-02 18:31 jasong GMP-ECM 6 2006-06-30 08:51 jasong Factoring 1 2006-04-03 17:18 jasong Factoring 27 2006-03-21 02:47

All times are UTC. The time now is 09:31.

Sat Dec 5 09:31:52 UTC 2020 up 2 days, 5:43, 0 users, load averages: 1.86, 1.69, 1.59