I have started YAFU on p^11-1 with digit size 112. I dont have an exact number (yet); but it´s about 940 numbers.

Most of them seem to have small factors, which should speed thinks up a bit. I can also take other numbers (e.g. p^19-1 (about ~1000 number with 112 digits)) after I´m finished with 112 digits.

One number takes about 6200 seconds NFS plus 2150 seconds for ECM. So far I had bad luck; 4 out of 5 had to be done with NFS, the last had an 26 digits factor. Co-Factor factored with SIQS.


I have no idea how long it will take, with ~6-8 numbers/day it will take ~130 days.

[QUOTE=MisterBitcoin;492644]I have started YAFU on p^11-1 with digit size 112. I dont have an exact number (yet); but it´s about 940 numbers.
[/QUOTE]

Just interestingly (for amateurs and experts) what SNFS polynom are you using for these?

[QUOTE=MisterBitcoin;492644]
One number takes about 6200 seconds NFS plus 2150 seconds for ECM. So far I had bad luck; 4 out of 5 had to be done with NFS,[/QUOTE]

I'm pretty sure you'll get more finished per day if you cut your ECM effort in half.

[QUOTE=R. Gerbicz;492646]Just interestingly (for amateurs and experts) what SNFS polynom are you using for these?[/QUOTE]


I´m using the polys found by YAFU. They have scores about e 8.415e-010.
YAFU´s poly search runs about 14 Minutes; while factmsieve.py only searches for ~3 minutes.
BUT: Booth gave me similar score values.

The poly instructions I got from RichD doesn´t seem to work. (probably due to "layer 8" problem :smile:) The poly I got from RichD for that C118 needed only 2,4M Relations; the msieve/Yafu polys need 7,65M Relations for lattice sieving. Looks like there is the problem.
Cutting pretest effort will help for sure.

[QUOTE=MisterBitcoin;492652]I´m using the polys found by YAFU. They have scores about e 8.415e-010.
[/QUOTE]

If the unfactored part is still "large" then doing this with Gnfs is a major overshoot, since these are
simply special numbers.
Asked this because when you check out such a number, say:
[url]http://www.factordb.com/index.php?query=%28810693844986229%5E11-1%29%2F%28810693844986229-1%29[/url]
(the given number is not interesting, just random)
and when you click on more information then there is an available option to get
[CODE]
Auto-generated SNFS-Polynominal available!
[/CODE]
you could think that it is optimal, but it is very far from that, lets see:

[CODE]
n=(p^11-1)/(p-1);

f(x)=p*x^5-1;
m=p*p;
f(m)%n
[/CODE]

so it is used a degree 5 polynom, but not used the known factor (p-1).
It was totally unable to recognize that it is a reciprocial polynomial, and we can get:

[CODE]
g(y)=y^5+y^4-4*y^3-3*y^2+3*y+1;
M=lift(Mod(p+1/p,n));
g(M)%n


? ? ? ? %25 = 0
? ? ? ? ? %28 = 0
[/CODE]
(so both polynomial is valid.)

After this writing searched the web, and found this:
[url]http://www.mersennewiki.org/index.php/SNFS_Polynomial_Selection[/url]
explaining the same thing.

All most wanted numbers with SNFS difficulty below 180 digits now done.



Now working on 6217^47-1 and 1091^59-1



As a matter of interest, is there any sort of target or score to work towards for the OPN bounds proofs? How many factor-weights might we need to allow the proof that there is no OPN with less than 2100 digits, for example?


Thanks
Steve

[QUOTE=Brownfox;492772]All most wanted numbers with SNFS difficulty below 180 digits now done.



Now working on 6217^47-1 and 1091^59-1



As a matter of interest, is there any sort of target or score to work towards for the OPN bounds proofs? How many factor-weights might we need to allow the proof that there is no OPN with less than 2100 digits, for example?


Thanks
Steve[/QUOTE]

I believe it is proven upto 2100 digits. The effort here is to reduce the difficulty to prove that and larger.

[QUOTE=MisterBitcoin;492644]I have started YAFU on p^11-1 with digit size 112. I dont have an exact number (yet); but it´s about 940 numbers.

Most of them seem to have small factors, which should speed thinks up a bit. I can also take other numbers (e.g. p^19-1 (about ~1000 number with 112 digits)) after I´m finished with 112 digits.

One number takes about 6200 seconds NFS plus 2150 seconds for ECM. So far I had bad luck; 4 out of 5 had to be done with NFS, the last had an 26 digits factor. Co-Factor factored with SIQS.


I have no idea how long it will take, with ~6-8 numbers/day it will take ~130 days.[/QUOTE]


Quick notice:
I have stopped this effort and moved the processing power on somethink more usefull.

Soon I´ll have 4 numbers ready for SNFS with size 165 digits; they all passed pretest t40; excluding one that also survived 6600 curves@43M.

These numbers have the form p^11-1; let me know if I should post them here or elswhere.

I can also do any other form, send me an file with numbers that need pretest and suggested deeph and I´ll do them.

It´s down to three numbers. (165 digits; form p^11-1)

These two reached t40:
[URL]http://www.factordb.com/index.php?id=1100000001076092952[/URL]
[URL]http://www.factordb.com/index.php?id=1100000001076093749[/URL]

This reached t50:
[URL]http://www.factordb.com/index.php?id=1100000001076094174[/URL]


I´m willing to do ECM pretests for any digit size <1200 digits from this project. Just send me the numbers via PM.

[QUOTE=MisterBitcoin;493593]It´s down to three numbers. (165 digits; form p^11-1)

These two reached t40:
[URL]http://www.factordb.com/index.php?id=1100000001076092952[/URL]
[URL]http://www.factordb.com/index.php?id=1100000001076093749[/URL]

This reached t50:
[URL]http://www.factordb.com/index.php?id=1100000001076094174[/URL][/QUOTE]

I'll take these three. More or less to finish them off so the ECM effort is not lost and possibly duplicated.

MWRB file
 

Reserving the following numbers from the MWRB file.
[CODE]1103^61-1
1129^61-1
1249^61-1
1783^61-1
1867^61-1[/CODE]