Pascal's OPN roadblock files

[MisterBitcoin]

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.

[R. Gerbicz]

Originally Posted by MisterBitcoin

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.

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

[VBCurtis]

Originally Posted by MisterBitcoin

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,

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

[MisterBitcoin]

Originally Posted by R. Gerbicz

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

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 ) 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.

[R. Gerbicz]

Originally Posted by MisterBitcoin

I´m using the polys found by YAFU. They have scores about e 8.415e-010.

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:
http://www.factordb.com/index.php?qu...844986229-1%29
(the given number is not interesting, just random)
and when you click on more information then there is an available option to get

Auto-generated SNFS-Polynominal available!

you could think that it is optimal, but it is very far from that, lets see:

n=(p^11-1)/(p-1);

f(x)=p*x^5-1;
m=p*p;
f(m)%n

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:

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

(so both polynomial is valid.)

After this writing searched the web, and found this:
http://www.mersennewiki.org/index.ph...mial_Selection
explaining the same thing.

[Brownfox]

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

[henryzz]

Originally Posted by Brownfox

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

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

[MisterBitcoin]

Originally Posted by MisterBitcoin

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.

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.

[MisterBitcoin]

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

These two reached t40:
http://www.factordb.com/index.php?id...00001076092952
http://www.factordb.com/index.php?id...00001076093749

This reached t50:
http://www.factordb.com/index.php?id...00001076094174


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

[RichD]

Originally Posted by MisterBitcoin

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

These two reached t40:
http://www.factordb.com/index.php?id...00001076092952
http://www.factordb.com/index.php?id...00001076093749

This reached t50:
http://www.factordb.com/index.php?id...00001076094174

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

[RichD]

Reserving the following numbers from the MWRB file.

1103^61-1
1129^61-1
1249^61-1
1783^61-1
1867^61-1