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. :max:

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 [i]return value[/i] ([b]NOT[/b] the output). I found short scripts on line that do this, but I don't understand the language.

[QUOTE=Dr Sardonicus;505626]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. :max:

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 [i]return value[/i] ([b]NOT[/b] the output). I found short scripts on line that do this, but I don't understand the language.[/QUOTE]

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.

[QUOTE=jyb;505629]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.[/QUOTE]It's still borked AFAICT.

[quote=jyb;504456]The following are all factors reported to me since the last update, through Dec. 26th. <snip>[/quote]
The [url=http://www.leyland.vispa.com/numth/factorization/anbn/main.htm]Homogeneous Cunningham numbers[/url] site is back up, and as far as I checked, had all the new data from the quoted post.

7-6_335
[CODE]prp75 = 229598680631885433367265926368682372432668526186133616419286306022691803541
prp56 = 60763052977326833156900039094453364793885836761103857491
[/CODE]

[QUOTE=VBCurtis;504341]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![/QUOTE]

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.

[QUOTE=VBCurtis;507144]
EDIT: I located a newer msieve binary, and am retrying filtering. The one I used initially was 1.52, oopsie.[/QUOTE]

...and a matrix built. Even at default density, it's not too big (7M). I'll have factors in a week or so.

[QUOTE=VBCurtis;507146]...and a matrix built. Even at default density, it's not too big (7M). I'll have factors in a week or so.[/QUOTE]

Indeed, you might have been seeing this: [url]https://mersenneforum.org/showpost.php?p=402719&postcount=47[/url].

7-4_313 factored
 

C123 cofactor of 7^313-4^313:

[CODE]prp64=3400573965346466446905317578185464922150898055196834374966000621
prp60=204001669044014281969176189515388927772294672082364068743861[/CODE]

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.

[QUOTE=VBCurtis;501462]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.[/QUOTE]

This octic is now complete:
[code]p50 factor: 33975868649651970899016905571752528467879050171601
p119 factor: 65135797998562415430798528249917370000456077731320932657143758869464297497211359496770902593185380419179035841099471781[/code]
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.

Becker considers me a spammer :surprised:(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][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
[/quote]