[QUOTE=rogue;627809]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.[/QUOTE]

This is fixed and committed to sourceforge.

For odd bases, all odd k are automatically removed.

[QUOTE=Citrix;627390]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.[/QUOTE]

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.
[/code]

Are you requesting this full functionality for such a switch in srsieve2?

[QUOTE=rogue;627983]The code is fixed and commited to sourceforge. This happens only with ABCD formatted output files.[/QUOTE]

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
[B]Fatal Error: Unable to allocate 8000000080 bytes of memory for N/A[/B][/CODE]

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 [I]srfile[/I] v1.1.4 from 2019. It is unable to read ABCD formats from [I]fbncsieve[/I]. I looked around for something newer but couldn't find one.

[I]Again, I am sorry for all this trouble.[/I] :blush:

[QUOTE=storm5510;628042]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
[B]Fatal Error: Unable to allocate 8000000080 bytes of memory for N/A[/B][/CODE]

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 [I]srfile[/I] v1.1.4 from 2019. It is unable to read ABCD formats from [I]fbncsieve[/I]. I looked around for something newer but couldn't find one.

[I]Again, I am sorry for all this trouble.[/I] :blush:[/QUOTE]

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.

[QUOTE=rogue;627987]

Are you requesting this full functionality for such a switch in srsieve2?[/QUOTE]

Yes, if possible. That would be very useful.
Note:- we do not need the {Percent}

Also, thank you for fixing the twinsieve code.

[QUOTE=rogue;628049]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.[/QUOTE]

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!

[QUOTE=storm5510;628072]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![/QUOTE]

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"

[QUOTE=Citrix;628083]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"[/QUOTE]

With tests that small most of the time in pfgw will be in overhead. Hence why sieving is done first.

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.

[QUOTE=Citrix;628083]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"[/QUOTE]

I extended it out to 10061955, which is my full birthdate. My starting k was 100e3. I wondered how [I]fbncsieve[/I] 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 [I]k[/I] vs. [I]n.[/I] This was resolved. [I]k=500[/I] and [I]n=500[/I] have the same numeric Base 10 weight.

I know how to use [I]pfgw[/I], but I didn't. [I]cllr64[/I] 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 [I]PowerShell[/I]. [I]cllr64[/I] ran one line then stopped. At least, I could read it. [I]srfile[/I] was not able to convert an ABCD file to npg from [I]fbncsieve[/I]. I ended up changing the output form to npg.

[I]srsieve2[/I] runs a variation very well. "10061955*6^n-1." n from 100e3 to 500e3. [I]cllr64[/I] 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. [B]gd_barnes[/B] 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.

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?