New srbsieve and related programs testing/fixes

[storm5510]

Originally Posted by gd_barnes

If you are aware of that, then why did you ask if the number of threads are more relative to srsieve2? Clearly you were not aware that we were talking about srsieve2 or you wouldn't have asked the question in the first place.

Storm, you can be very abrasive in picking on us about cores, threads, and workers. We all know what we are talking about. Several times you've made comments about people "mixing up" these things. We aren't mixing them up at all. We are simply using conversationally loose language. He knew what he meant. I knew what he meant. Anybody else observing the conversation would know what the two of us meant.

Please make no more comments about cores, threads, and workers. It's getting very old.

I don't want to be put into the sweety439 category, so I will simply stay away from all this completely!

[VBCurtis]

Originally Posted by storm5510

I don't want to be put into the sweety439 category, so I will simply stay away from all this completely!

It's not really for me to tell you what to do, but if you just ease up on adding complaints to threads when your work is working, you're a whole lot less likely to get reminded that you're confused / in the wrong thread / complaining about something that has already been addressed as best we can.

You've had rather a few posts recently that amount to "I don't like that Pepsi has sugar" in a thread about Diet Coke. But when you post that you can't get the Diet Coke open, Gary & co still do their best to help you open the can.

[gd_barnes]

Attached is updated srbsieve 1.8.3.

Changes:

1. Added option to use multi-thread srsieve2. In the folder is an updated srbsieve.ini. Change threadsrsieve2=x as needed. If the line item is not present or is set to 0, srsieve2 will default to 1 thread. I did not set a maximum value for it. If it's more than your machine's number of threads, it will attempt to use them all.

2. Added logic to do work on the pl_unknown.txt files. The unknown file will pop up if pfgw is unable to prove a PRP as prime. This should stop them from occurring in likely > 99% of cases. The logic added is similar to what the old starting bases script did. If a "regular" primality test with the -tm or -tp option doesn't prove a PRP, it attempts a combined test with -tc. If that doesn't prove it, if the form is <= 20 digits, it will trial factor it to the square root of the form, which is a guaranteed proof of whether it is prime or composite. It's still remotely possible for pfgw to find a PRP that turns out to be composite but if that happens it's likely going to be because maxNfbncsieve was set too low to begin with -or- there's a bug in pfgw. Bottom line: In this process, if a prime is proven, it will write it to the pl_prime.txt file like it would any other prime and no unknown file will be written.

3. Added additional error checking on the srbsieve.ini inputs for negative numbers. I found that there were unpredictable results if you had a negative value in some of the fields. This is due to the fact that most of the variables are defined as unsigned so the program would read them as very large positive values.