One other tidbit. If the number also appears in t800 and less than a C190, then those have been ECMed to t50.

Is there another mailing list/source/other for such information? Or are you just aware from private correspondence of work others are doing.

I don't know of any other sources (other than this thread) for tracking these numbers. If there is one, I would submit what I know to their database. I am just repeating what has already been mentioned previously.

I usually keep track of several hundred numbers, that I am interested in, at any given time.

Sadly, Pascal does not keep detail records of ECM work per [URL=http://www.mersenneforum.org/showpost.php?p=470564&postcount=553]this post[/URL].

[QUOTE=RichD;476801]Sadly, Pascal does not keep detail records of ECM work per [URL=http://www.mersenneforum.org/showpost.php?p=470564&postcount=553]this post[/URL].[/QUOTE]That is unfortunate. :down:

The 4 numbers reserved in my previous post are nearly complete now, and the smallest factor so far has been 46 digits, so I don't feel too bad about not trying more ECM.

I am looking at [URL="http://www.factordb.com/index.php?query=%28201663262153%5E17-1%29%2F201663262152"]201663262153^17-1[/URL] now, which appears in t800.

As I see it there are a few options here:

Degree 5, SNFS 193 with bad coefficients
Degree 6, SNFS 204 with better coefficients
Degree 8, SNFS 181 with amazing coefficients, but you know, degree 8

Degree 5 but GNFS 158

Or there's always the ECM and hope approach too.

I'm curious to know what method others here would take, I'd guess the degree 6?

I started sieving with the degree 8 poly, and on the rational side it was pretty slow. But on the algebraic side, it is muuuuuch faster. I have heard though that there can be issues in the final stages with a degree 8, and clearly a degree 8 is not optimal for numbers of this size. To that end I tested it on a SNFS 115, and it seemed to work without issue, so I remain hopeful.

I think I will continue with this number and degree 8 poly. I estimate it will take 4 days assuming no issues crop up. I may also attempt the factorisation with the degree 6 poly as well and see how the time compares.

[QUOTE=lavalamp;477094]I am looking at [URL="http://www.factordb.com/index.php?query=%28201663262153%5E17-1%29%2F201663262152"]201663262153^17-1[/URL] now, which appears in t800.

As I see it there are a few options here:

Degree 5, SNFS 193 with bad coefficients
Degree 6, SNFS 204 with better coefficients
Degree 8, SNFS 181 with amazing coefficients, but you know, degree 8

Degree 5 but GNFS 158

Or there's always the ECM and hope approach too.

I'm curious to know what method others here would take, I'd guess the degree 6?[/QUOTE]

This is a tough one to call. Both SNFS-204 (6-deg) and GNFS-158 (5-deg) are easy 30-bit/14e jobs. You might be able to fit the GNFS job in as a 29-bit. The SNFS-204 would require sieving on the algebraic side. Better yet, it might turn out better if you could do 2/3 to 3/4 on the algebraic side and the small remainder on the rational side but that requires manual intervention. If you want to fire and forget then the GNFS *might* be the way to go.

I tested degree 8 with p^17-1 and found the cut-over point to be above SNFS-230. Then again, I didn't test anything this low. There might be a small window for 8-deg.

[QUOTE=RichD;477110]This is a tough one to call. Both SNFS-204 (6-deg) and GNFS-158 (5-deg) are easy 30-bit/14e jobs. You might be able to fit the GNFS job in as a 29-bit. [/QUOTE]I'm going to assume this is something to do with the lattice sieving, I see there are many lasieve exe's, but I've no idea why or what they do. Much learnings still to do, my knowledge of GNFS is still remarkably poor.

[QUOTE=RichD;477110]The SNFS-204 would require sieving on the algebraic side. Better yet, it might turn out better if you could do 2/3 to 3/4 on the algebraic side and the small remainder on the rational side but that requires manual intervention. If you want to fire and forget then the GNFS *might* be the way to go.[/QUOTE]I'm using factmsieve.py, so it's essentially already fire and forget for me. I did a little test sieving and found that on the rational side, both the degree 6 and degree 8 poly sieved at about the same rate, but then on the algebraic side, the degree 8 is over 10 times faster. I didn't test the degree 6 on the algebraic side, perhaps I should have.

[QUOTE=RichD;477110]I tested degree 8 with p^17-1 and found the cut-over point to be above SNFS-230. Then again, I didn't test anything this low. There might be a small window for 8-deg.[/QUOTE]Do you mean use degree 6 below 230 and degree 8 above?

[QUOTE=lavalamp;477115]I'm going to assume this is something to do with the lattice sieving, I see there are many lasieve exe's, but I've no idea why or what they do. Much learnings still to do, my knowledge of GNFS is still remarkably poor.[/QUOTE]
Each lasieve application sieves a different area for each input Q. In a sense, this area is akin to how hard the siever tries to find relations for each Q. For easier tasks, relations come easily and it's not very valuable to search harder for each Q (rather, one just moves on to the next Q, harvesting the easy relations to be found there).
As tasks get harder, the smaller siever struggles to find relations, and doesn't find very many per Q. So, we move to a larger siever.
For GNFS tasks (the ones where poly select happens, no special form to the number), 12e is used up to about 120 digits, 13e from 120 to low 140s, 14e from low 140s to high 160s, 15e from high 160s to high 180s, and 16e above that (there isn't a 17e). These cutoffs are editable in your factmsieve file, on a line that looks like (mine is edited from default as a result of experimentation):
[code] if nfs_type == 'gnfs':
r = (95, 118, 141, 166, 185, 999)[/code]
The SNFS cutoffs are adjacent.

In general, going up one siever will find twice as many relations per Q, but use four times the memory.

Large primes choices are the other number mentioned (30 or 29); that takes a bit more to explain, but I can make an attempt if you'd like. Factmsieve makes those choices in the code just above the snippet I quoted, on lines marked "lpba" and "lpbr".

I use the algebraic side for p^17-1 (and p^19-1). The curve peters off pretty quick. Once the yield drops below the rational side sieving I thought it might be advantageous to perform some sieving on that side until its curve drops off. Then back to the algebraic side.

I tried this once but it didn't work out as well as I hoped because of the high number of dups. It still solved the problem. It just needs a bit of tweeking but I moved on to other numbers at the time.

To fire and forget, the -a side would be better.

Hi, I'm new to this project.

I decided to throw some spare CPU cycles toward running ECM on the composites in the t2100 file and have already found six factors while running at B1=11e3. Where should I report the factors that I've found?

[url]http://factordb.com[/url] is the most common repository for factors.

And I found another factor since my last post. The factors have all been entered into factordb.

C703 = P24 * C679 [url]http://factordb.com/index.php?id=1100000000636616851[/url]

C703 = P24 * C679 [url]http://factordb.com/index.php?id=1100000000685523992[/url]

C707 = P23 * C685 [url]http://factordb.com/index.php?id=1100000000685525904[/url]

C756 = P26 * C731 [url]http://factordb.com/index.php?id=1100000000450870183[/url]

C883 = P22 * C862 [url]http://factordb.com/index.php?id=1100000000685533830[/url]

C891 = P24 * C868 [url]http://factordb.com/index.php?id=1100000000685534226[/url]

C892 = P21 * C871 [url]http://factordb.com/index.php?id=1100000000685534256[/url]