Testing new Ranges for Sierpinski/Riesel

[rogue]

I added a print out of the k remaining, but it is only printed after a phase is completed.

[pepi37]

Phase 5: Processing k from 302 to 964
command: srsieve -q -m1e10 -P58181000 -n1281 -N2560 -w sieve.in
command: pfgw64 -Cquiet -f0 sr_b.pfgw > nul
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
ABC File Processing for at most 1 Primes


1 file(s) moved.
command: pfgw64 -Cquiet -tm sr_b.prp > nul
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]


1 file(s) moved.
Phase 6: Processing k from 302 to 964
command: srsieve -q -m1e10 -P73588000 -n2561 -N3072 -w sieve.in
command: pfgw64 -Cquiet -f0 sr_b.pfgw > nul
PFGW Version 3.7.10.64BIT.20150809.Win_Dev [GWNUM 28.6]

No factoring at all, not even trivial division
ABC File Processing for at most 1 Primes

I dont see the number of remain candidate, do you see it?

[rogue]

KEP reported a bug with Sierpinski mew base searching. This bug causes srbsieve to miss MOBs. Fortunately you don't need to re-run an entire range (or generate inputs from newpgen) to find the missing values. Run the new version and it will output an updated pl_MOB.txt.. If any of those k show up in your pl_remain.txt file, remove them.

[rogue]

I made a small change to address a problem found by MisterBitcoin. newpgen will sieve to sqrt(largest candidate) and srbsieve checks for that, but it turns out that newpgen will sometimes sieve to the largest prime less than sqrt(largest candidate) and not the smallest prime greater than sqrt(largest candidate). With the current behavior, srbsieve terminates with an error. I added a check to allow for the difference so that srbsieve will not terminate. The check isn't perfect, but for the large ranges of k being tested, it shouldn't be a problem. There is a very, very slim chance that someone could terminate newpgen early and srbsieve will allow for the file without giving the error. By early, I mean stopping newpgen within a few hundred primes of which it would sieve to, which could probably only happen if someone were deliberately trying to break it.

[MisterBitcoin]

I found an other bug, this time its something small.

These progress on phase 8 was not 0,23 pct. This is happening because the progress for phase 8 is using the same sub-phase-amount from phase 2. :)

[rogue]

Originally Posted by MisterBitcoin

I found an other bug, this time its something small.

These progress on phase 8 was not 0,23 pct. This is happening because the progress for phase 8 is using the same sub-phase-amount from phase 2. :)

I don't see a problem in the code. Did you stop and restart the range at some point? Can you e-mail me the input files you used?

[MisterBitcoin]

Originally Posted by rogue

I don't see a problem in the code. Did you stop and restart the range at some point? Can you e-mail me the input files you used?

All ready too late. But I can see the same think on S7/15. So far I got it right:

The progress that srbsieve prints out it using the amount of sub-phases. You will have a few hundred sub-phases in phase 2, but only the few in phase 16.

The process from S7 and S15 is running with any disruption.

Anyway: k´s remain print out function isn´t working. Pepi just pointed it out a few month ago.
These thinks are optional, personally I don´t need them. Just nice to have.

[rogue]

Originally Posted by MisterBitcoin

All ready too late. But I can see the same think on S7/15. So far I got it right:

The progress that srbsieve prints out it using the amount of sub-phases. You will have a few hundred sub-phases in phase 2, but only the few in phase 16.

The process from S7 and S15 is running with any disruption.

Anyway: k´s remain print out function isn´t working. Pepi just pointed it out a few month ago.
These thinks are optional, personally I don´t need them. Just nice to have.

I see why it isn't outputting the remaining k's. It builds a string with the information but doesn't dump it to the screen.

I still need to see some files for the other issue. I'm not seeing any problems in the code yet.

[rogue]

I just discovered that Ken Brazier has a program called nsieve64. This can work like newpgen, but is 64-bit. As it is source, it can be compiled on other platforms. It claims to be faster than newpgen.

I'll take a look and see if it can be multi-threaded. It could also benefit by accepting parameters the way other sieving programs do.

It does seem to have other issues as it doesn't correctly parse inputs > 32 bits, but that should be easy to address.

[pepi37]

Originally Posted by rogue

I just discovered that Ken Brazier has a program called nsieve64. This can work like newpgen, but is 64-bit. As it is source, it can be compiled on other platforms. It claims to be faster than newpgen.

I'll take a look and see if it can be multi-threaded. It could also benefit by accepting parameters the way other sieving programs do.

It does seem to have other issues as it doesn't correctly parse inputs > 32 bits, but that should be easy to address.

Can you build exe file: to start learning what this program can make?
I try to build it, but got many errors :(

[wombatman]

Originally Posted by pepi37

Can you build exe file: to start learning what this program can make?
I try to build it, but got many errors :(

If you have Windows 10, it will build in the Ubuntu shell with

g++ nsieve64.cpp -o nsieve64

And testing with

./nsieve64 -s 6209,800000000,800000001 -N 6299 -o nsieve64_testoutput.txt -p 2,1000000000000

seems to be working. One note: you cannot currently use abbreviated inputs like 1e12; they must be typed out fully.