mtsieve

[rogue]

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.

[rogue]

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:

   -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?

[storm5510]

Originally Posted by rogue

The code is fixed and commited to sourceforge. This happens only with ABCD formatted output files.

Something else:

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.

[rogue]

Originally Posted by storm5510

Something else:

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.

[Citrix]

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.

[storm5510]

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!

[Citrix]

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"

[henryzz]

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.

[rogue]

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.

[storm5510]

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.

[rogue]

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?