20230407, 15:36  #1112  
"Mark"
Apr 2003
Between here and the
7,487 Posts 
Quote:
For odd bases, all odd k are automatically removed. Last fiddled with by rogue on 20230407 at 15:36 

20230407, 15:43  #1113  
"Mark"
Apr 2003
Between here and the
7,487 Posts 
Quote:
Code:
f[percent][[{Mod_Expr}][{condition}[{condition}...]]] Modular factoring: f{801} uses only primes which are of the form k*801+1 f{632,1} uses only primes which are of the form k*6321 ** The {801} and the {632,1} are the optional {Mod_Expr} *** NOTE new code added to do both 1 and +1. the format would be f{801,+1} (the +1 MUST look just like that) f{256}{y,8,1) uses only primes which are of the form k*256+1 where the resultant primes are also of the form j*8+1 f{256}{n,8,1) uses only primes which are of the form k*256+1 where the resultant primes are not of the form j*8+1 f500{256}{y,8,1){y,8,7){n,32,1) uses only primes which are of the form k*256+1 where the resultant primes are also of the form j*8+1 but not j*32+1. There is also a 500% factoring level. f{8132}{y,8,1){f,8132} uses only primes which are of the form k*8132+1 where the resultant primes are also of the form j*8+1. Also, all factors of 8132 (2,19,107) are checked first. f{8132}{y,8,1){p,8133} uses only primes which are of the form k*8132+1 where the resultant primes are also of the form j*8+1. Also, ALL primes <= 8133 are checked first. 

20230408, 15:02  #1114  
Random Account
Aug 2009
Oceanus Procellarum
3,041 Posts 
Quote:
Code:
fbncsieve v1.6, a program to find factors of k*b^n+c numbers for fixed b, n, and c and variable k Sieve started: 3 < p < 1e9 with 50001 terms (100000 < k < 200000, k*1955^6+1) (expecting 47350 factors) Increasing worksize to 1600000 since each chunk is tested in less than a second Increasing worksize to 200000000 since each chunk is tested in less than a second Fatal Error: Unable to allocate 8000000080 bytes of memory for N/A Changing the values behind the caret results in different behaviors. 6+1 is not a good choice. 2+1 generates the previous error. 21 and 31 are alright. I have probably been trying to make the program do what it was not designed for. I have srfile v1.1.4 from 2019. It is unable to read ABCD formats from fbncsieve. I looked around for something newer but couldn't find one. Again, I am sorry for all this trouble. 

20230408, 16:58  #1115  
"Mark"
Apr 2003
Between here and the
7,487 Posts 
Quote:


20230408, 23:27  #1116 
Jun 2003
7·233 Posts 

20230409, 00:00  #1117  
Random Account
Aug 2009
Oceanus Procellarum
3,041 Posts 
Quote:
In any case, I will leave this alone and move on to other things. Again, sorry for all the trouble! 

20230409, 08:19  #1118  
Jun 2003
1631_{10} Posts 
Quote:
This is too small causing the program to be too fast and hence requiring large amounts of memory. You are better off using pfgw directly for such small numbers. Try replacing it with "k*1955^60000+1" 

20230409, 11:41  #1119 
Just call me Henry
"David"
Sep 2007
Liverpool (GMT/BST)
23×271 Posts 
With tests that small most of the time in pfgw will be in overhead. Hence why sieving is done first.

20230409, 13:36  #1120 
"Mark"
Apr 2003
Between here and the
16477_{8} Posts 
For some sieves, such as twinsieve and fbncsieve, there is a secondary buffer where primes passing the first phase of the sieve are put into a second buffer for the second phase. So when the number of primes per chunk grows, so does the need for additional memory. This can be a problem because those sieves are so fast that each chunk is really large which put strain on the memory utilization.
The solution requires two changes. First, eliminate that secondary buffer. Second, add a parameter to limit the maximum number of primes per chunk. 
20230409, 18:07  #1121  
Random Account
Aug 2009
Oceanus Procellarum
101111100001_{2} Posts 
Quote:
I know how to use pfgw, but I didn't. cllr64 didn't like the taste of the input npg file. The console screen text went from the default light gray to a deep blue which I could not read on a black background. I tried it in PowerShell. cllr64 ran one line then stopped. At least, I could read it. srfile was not able to convert an ABCD file to npg from fbncsieve. I ended up changing the output form to npg. srsieve2 runs a variation very well. "10061955*6^n1." n from 100e3 to 500e3. cllr64 accepted the converted npg file just fine. I got to a point where I needed to get away from the formal GIMPS work and the side projects. Running R42 for CRUS got a little stressful. It took 39 days to get it to P=4e13. gd_barnes was pleased with the effort. So, I end up jumping around running one thing or another. Nothing to be submitted. Just goofing. I find it relaxing. 

20230409, 21:04  #1122 
"Mark"
Apr 2003
Between here and the
7,487 Posts 
Regarding the memory issue I’m thinking about using the w switch to lock the size of each prime chunk. Without w, it will auto adjust the chunks as it runs. This would be easy to implement. Thoughts?
