Bases 6-32 reservations/statuses/primes

[gd_barnes]

David,

Unfortunately your listing of k's remaining for this range is incorrect. A double check by Karsten showed that there are over 200 k's remaining at n=1000. Due to lack of time, I did not doublecheck you. I simply took your list and removed appropriate MOB to give you the list.

Please rerun your range and I will check it against Karsten's list. If they don't match up a 2nd time, I would suggest that you not test the range any further and consider extending existing ranges. When you are first learning to run new ranges, it is better if you run the range manually instead of using any automated tools. Then come up with your own way to determine k's remaining. That will give you a feel for what it takes to get down to a correct # of k's remaining.

For doing it manually, I just use a stand-alone simple PFGW script with the -l switch set on and the stop-on-prime set on in the script. I do not sieve and I use the -f100 switch in PFGW for trial factoring. I usually test up to n=5000 using PFGW trial factoring before beginning sieving but that is my personal choice, not necessarily the most efficient one. It's pretty quick and simple. I then look in pfgw.out and look at the last exponent. In this case, you'll only run even k's but you'll still have k's where k==(1 mod 7) so you'll need to ignore those. That will get you to your "initial" list of k's remaining. From there, you can start removing correct MOB. For this run, pfgw.out should be quite large but I think you'll still find it managable to pull up and view the final exponent for k's remaining. (Make sure you don't include k's remaining where a prime was found exactly at n=1000.)

This method is quite crude and rudimentary but I believe it is an excellent learning tool for getting started with new bases or k-ranges.


To all,

Please be very careful when running new k-ranges or bases. I can't stress this enough and can't doublecheck everyone's runs. Please do NOT take on new bases or new ranges of k's unless you know exactly what you are doing. We are talking mathematical conjectures that have to be proven at some point. If you can't demonstrate primes for all appropriate k's, they must continue being searched.

If I sound like a lecturing broken record, then that is what I must be to get the point across. Searching k's that don't need to be searched such as for multiples of the base that should be removed is a small error and a moderate waste of CPU errors. Eliminating k's that should be searched like in this case is a grave error. Please be careful and doublecheck yourself if you are not clear on this.

Leaving out over 100 k's that still need primes would not have been a good thing.

Thanks for the doublecheck Karsten!


Gary

[henryzz]

ouch!!
i have discovered a couple of reasons
i had actually tested up to n=2k
i tested with PFGW 3.2
when i tested the prps for primality PFGW 3.2 said some 50 were composite
i just retested the prps with PFGW 1.2 and all the prps were prime
i will rerun with PFGW 1.2 to n=1K removing ks where:
k = 1 mod 3
k = 1 mod 7

this should be correct
i have used this script before successfully on windows before(i am now on linux)

if this doesn't work then i will go back to the old way you suggested

[rogue]

Originally Posted by henryzz

ouch!!
i have discovered a couple of reasons
i had actually tested up to n=2k
i tested with PFGW 3.2
when i tested the prps for primality PFGW 3.2 said some 50 were composite

PFGW 3.2 had an issue with the primality test of some numbers. A problem was fixed in 3.2.1. You need to communicate issues like this with me otherwise issues like this don't get resolved and it undermines the usefulness of the software.

[kar_bon]

Originally Posted by henryzz

i will rerun with PFGW 1.2 to n=1K removing ks where:
k = 1 mod 3
k = 1 mod 7

you mean base=15, correct?

so look here: http://www.noprimeleftbehind.net/cru...onjectures.htm

and there's given for trivial k's:
k == 1 mod 2
k == 1 mod 7

!!!

[henryzz]

Originally Posted by kar_bon

you mean base=15, correct?

so look here: http://www.noprimeleftbehind.net/cru...onjectures.htm

and there's given for trivial k's:
k == 1 mod 2
k == 1 mod 7

!!!

typo in my post not the script fortunately

[henryzz]

Originally Posted by rogue

PFGW 3.2 had an issue with the primality test of some numbers. A problem was fixed in 3.2.1. You need to communicate issues like this with me otherwise issues like this don't get resolved and it undermines the usefulness of the software.

so it is safe for me to use 3.2.1 for prp tests on these numbers
i couldnt reproduce the faults with -q earlier on 3.2
should i be using anything like -a2?

[rogue]

Originally Posted by henryzz

so it is safe for me to use 3.2.1 for prp tests on these numbers
i couldnt reproduce the faults with -q earlier on 3.2
should i be using anything like -a2?

The issue fixed in 3.2.1 was with the primality test, not the PRP test. There is a bug in 3.2.1 with PRP tests of +1 numbers. It produces the correct result, but takes a lot longer because it is using a slower form of modular reduction. I will fix that by the weekend.

[gd_barnes]

Originally Posted by rogue

PFGW 3.2 had an issue with the primality test of some numbers. A problem was fixed in 3.2.1. You need to communicate issues like this with me otherwise issues like this don't get resolved and it undermines the usefulness of the software.

I think you guys are talking about 2 different things. Communication error.

Mark, it is expected that some very small PRP's will be composite. I doubt this is a software problem. The rounding error that came up before might miss a prime but not the other way around.

David, are you trial factoring with the -f100 switch? It's unusual to have so many PRP's that are composite.

One more thing David, can you please use some punctuation and capitalization in your postings, especially when spelling out a technical issue? Your posts can be hard to understand at times. With many people on here where English is not their native language, that would help greatly. Thank you.

[henryzz]

Originally Posted by gd_barnes

I think you guys are talking about 2 different things. Communication error.

Mark, it is expected that some very small PRP's will be composite. I doubt this is a software problem. The rounding error that came up before might miss a prime but not the other way around.

David, are you trial factoring with the -f100 switch? It's unusual to have so many PRP's that are composite.

One more thing David, can you please use some punctuation and capitalization in your postings, especially when spelling out a technical issue? Your posts can be hard to understand at times. With many people on here where English is not their native language, that would help greatly. Thank you.

Sorry for confusing you.
It was the primality test that was at fault not the prp test.
My results should have been right for n=2k.

I think i did use the -f100 switch in the end.
I did discover that for low values of k -f0 was faster.

Sorry I am trying to remember to type with punctuation. Unfortunately I got into a habit of not doing. Especially since I became a mod I have been trying. You might notice that I remember more often in the aliquot forum.

I am currently running it up to n=1k with both 3.2.1 and 1.2 to make a comparison.
@rogue
Would it be possible for PFGW to have an option that makes it run prp tests and if a prp is found then it will be primality tested with -t, -tp, or -tc?

[henryzz]

Here is the remaining ks list for my rerun with PFGW 1.2 up to n=1k(1k is correct this time).
There are 216 ks remaining before removing ks that are k = 0 mod 15 and k-1 is not prime.
Does anyone have a working script to do the removal of those ks?

edit: forgot the attachment like usual

[kar_bon]

@Gary:

perhaps it's better to shift those related posts from here to "Automated testing for all bases and k/n"!

i'll try to update the MOB-pass with changing for all Riesel-bases as parameter, so a call like "MOB_do 15" for base 15.
After this the MOB and the Automated_low_n will combined in the latter one!

Edit: Done.