mersenneforum.org mtsieve
 Register FAQ Search Today's Posts Mark Forums Read

2023-04-07, 15:36   #1112
rogue

"Mark"
Apr 2003
Between here and the

7,487 Posts

Quote:
 Originally Posted by rogue For base 2, even k are already removed, so you don't need -r. I broke this in 1.6. I will fix the code.
This is fixed and committed to sourceforge.

For odd bases, all odd k are automatically removed.

Last fiddled with by rogue on 2023-04-07 at 15:36

2023-04-07, 15:43   #1113
rogue

"Mark"
Apr 2003
Between here and the

7,487 Posts

Quote:
 Originally Posted by Citrix Is it possible in the next release we could have a command line option to limit primes being tested to certain classes (similar to pfgw -f{n,+-1}). The program currently does not automatically catch these.
This is what pfgwdoc.txt has for -f:

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*632-1
** 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.
Are you requesting this full functionality for such a switch in srsieve2?

2023-04-08, 15:02   #1114
storm5510
Random Account

Aug 2009
Oceanus Procellarum

3,041 Posts

Quote:
 Originally Posted by rogue The code is fixed and commited to sourceforge. This happens only with ABCD formatted output files.
Something else:
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
This particular system has 16GB or RAM.

Changing the values behind the caret results in different behaviors. 6+1 is not a good choice. 2+1 generates the previous error. 2-1 and 3-1 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.

2023-04-08, 16:58   #1115
rogue

"Mark"
Apr 2003
Between here and the

7,487 Posts

Quote:
 Originally Posted by storm5510 Something else: 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 This particular system has 16GB or RAM. Changing the values behind the caret results in different behaviors. 6+1 is not a good choice. 2+1 generates the previous error. 2-1 and 3-1 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.
Your computer does not have enough memory for the buffer of primes. That is something I haven't run into, but is certainly possible with fbncsieve and gfndsieve (and possibly others). I will see what I can do to address this.

2023-04-08, 23:27   #1116
Citrix

Jun 2003

7·233 Posts

Quote:
 Originally Posted by rogue Are you requesting this full functionality for such a switch in srsieve2?
Yes, if possible. That would be very useful.
Note:- we do not need the {Percent}

Also, thank you for fixing the twinsieve code.

2023-04-09, 00:00   #1117
storm5510
Random Account

Aug 2009
Oceanus Procellarum

3,041 Posts

Quote:
 Originally Posted by rogue Your computer does not have enough memory for the buffer of primes. That is something I haven't run into, but is certainly possible with fbncsieve and gfndsieve (and possibly others). I will see what I can do to address this.
Unless I miscounted the digits in the error message, I believe it is indicating a smidge over 8GB. I have 16GB in this system. Roughly 13GB is available at idle.

In any case, I will leave this alone and move on to other things. Again, sorry for all the trouble!

2023-04-09, 08:19   #1118
Citrix

Jun 2003

163110 Posts

Quote:
 Originally Posted by storm5510 Unless I miscounted the digits in the error message, I believe it is indicating a smidge over 8GB. I have 16GB in this system. Roughly 13GB is available at idle. In any case, I will leave this alone and move on to other things. Again, sorry for all the trouble!
I think the problem is with "k*1955^6+1"

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"

2023-04-09, 11:41   #1119
henryzz
Just call me Henry

"David"
Sep 2007
Liverpool (GMT/BST)

23×271 Posts

Quote:
 Originally Posted by Citrix I think the problem is with "k*1955^6+1" 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"
With tests that small most of the time in pfgw will be in overhead. Hence why sieving is done first.

 2023-04-09, 13:36 #1120 rogue     "Mark" Apr 2003 Between here and the 164778 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.
2023-04-09, 18:07   #1121
storm5510
Random Account

Aug 2009
Oceanus Procellarum

1011111000012 Posts

Quote:
 Originally Posted by Citrix I think the problem is with "k*1955^6+1" 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"
I extended it out to 10061955, which is my full birthdate. My starting k was 100e3. I wondered how fbncsieve would respond to a number evenly divisible by 5. The program ran this very fast. This speed was what got me wondering about the absolute values of k vs. n. This was resolved. k=500 and n=500 have the same numeric Base 10 weight.

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^n-1." 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.

 2023-04-09, 21:04 #1122 rogue     "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?

All times are UTC. The time now is 02:48.

Wed Oct 4 02:48:59 UTC 2023 up 21 days, 31 mins, 0 users, load averages: 1.20, 1.04, 0.95