20100530, 22:38  #1 
Mar 2010
3·137 Posts 
Which poly to use?
Howdy, folks. So I decided to factor RSA100.Again.
I got 2 Polys using Msieve 1.45 with a CUDA GPU. Here's first: Code:
N 1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139 SKEW 554753.83 R0 532756497435146513887571 R1 103288101097409 A0 6146189103866429094136080 A1 308188141461002143706 A2 28188889873255477 A3 2347896070 A4 18900 Code:
N 1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139 SKEW 900108.23 R0 635116372672313959258675 R1 91841463772921 A0 2510713546966177126893631144 A1 5674926898539175329782 A2 10050582327235661 A3 15172642638 A4 9360 And, how can I tell it's better? Karl. 
20100531, 01:31  #2 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,257 Posts 
The first one is a bit better:
it has larger norm, larger (in abs.value) alpha, and larger Murpy E score. p1: skew 554753.83, size 1.511335e13, alpha 5.390549, combined = 1.409e08 p2: skew 900108.23, size 1.389628e13, alpha 5.127882, combined = 1.383e08 
20100531, 08:17  #3 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,257 Posts 
I found a slightly better poly:
Code:
# norm 1.472430e013 alpha 5.486015 e 1.429e008 skew: 894207.14 c0: 258649450348138371326825455 c1: 5399499758071374808669 c2: 11401030669362863 c3: 10289778325 c4: 3450 Y0: 815128765602942897511404 Y1: 86029790665901 
20100531, 09:53  #4 
Mar 2010
3·137 Posts 
I bet that poly was found using GGNFS.
I wasnt able to get poly.exe running from that suite. It crashed right after initialization. 
20100601, 15:26  #5 
Mar 2010
3·137 Posts 
What is a "degree" of a polynominal?
GGNFS polyselector didnt want to start untill I specified the degree. I try to use GGNFS siever(gnfslasieve4I13e.exe) for sieving phase. Here's how rsa100.poly looks like: Code:
name: rsa100 n: 1522605027922533360535618378132637429718068114961380688657908494580122963258952897654000350692006139 Y0: 532756497435146513887571 Y1: 103288101097409 c0: 6146189103866429094136080 c1: 308188141461002143706 c2: 28188889873255477 c3: 2347896070 c4: 18900 skew: 554753.83 type: gnfs Now, why is that?How can I fix it? 
20100601, 16:17  #6 
(loop (#_fork))
Feb 2006
Cambridge, England
18E9_{16} Posts 
You need to set the eight bounds: alim, rlim, lpbr, lpba, mfbr, mfba, alambda, rlambda. The factMsieve.pl script encodes a fair amount of the knowledge we have on how to set these bounds for numbers of different sizes; for 100 digits, alim=rlim=2000000, lpbr=lpba=24 should be about right. And in general alambda=rlambda=2.6 and mfbr=2*lpbr, mfba=2*lpba seem to work well.

20100601, 17:25  #7 
Mar 2010
3·137 Posts 
Thanks Tom for the advice.
Is there a way to feed a poly to factmsieve.py script? Last fiddled with by Karl M Johnson on 20100601 at 17:30 
20100601, 17:39  #8 
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
5793_{10} Posts 
just put the stuff in post 5 into a file with extension .poly

20100601, 17:43  #9 
Mar 2010
633_{8} Posts 
Results in
Code:
C:\Program Files (x86)\msieve\ggnfs\example>factmsieve.py example.poly > ________________________________________________________________ >  Running factmsieve.py, a Python driver for MSIEVE with GGNFS  >  sieving support. It is Copyright, 2010, Brian Gladman and is  >  a conversion of factmsieve.pl that is Copyright, 2004, Chris  >  Monico. Version 0.68 (Python 2.6 or later) 24th April 2010.  > ______________________________________________________________ > This is client 1 of 1 > Using 4 threads > Working with NAME = example Could not find default parameter file ../defpar.txt! Last fiddled with by Karl M Johnson on 20100601 at 17:43 
20100601, 18:32  #10  
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
3·1,931 Posts 
Quote:
also permissions probably wont be right in programfiles in either vista or windows 7 we have learnt to avoid it like the plague here 

20100601, 18:56  #11  
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,257 Posts 
Quote:
Here's how the funny looking poly was found. I recompiled msieve_gpu with MULTIPLIER relaxed to 30, ...and later to 2 (and then I found a poly with c4=72, e=1.438e08; this is probably as good a poly as it gets. Your standard polys were also reported, rank #3,4. This was done out of curiosity. Bottom line: this trick steals from the speed of search and the increment in the poly is insignificant. Also, with a difference in E so small, I won't be surprised if a test sieving would rerank these polys, anyway). 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Poly search candidates  schickel  Msieve  32  20131105 19:11 
Good enough poly for c155?  theuser  Msieve  4  20121007 09:00 
GNFS poly selection  frmky  Factoring  14  20120723 01:57 
Can someone run a couple of poly searches for me?  schickel  Msieve  12  20120525 03:45 
poly selection in MPQS  bsquared  Factoring  3  20070228 14:22 