Sierpinski base 4

[Citrix]

Originally Posted by tcadigan

Mystwalker...so...just stating the obvious...you'd get the dat for the most recent zip posted...rename it to SoB.dat and then follow the rest of geoff's instructions.

whenever you're done make the results available, I seem to have taken up that since there isn't a whole lot of movement in the project and it's just as easy for me to do it as anyone else

The Sob.dat in the Zip is outdated. You can remove the stuff below 1.5M for my k. Should be give atleast a 10% boost.

[tcadigan]

there updated with the last time Jean reported...and where I'm currently at...and what Citrix has done

dat file dropped for 90 kb to 75 kb

[Jean Penné]

Excuse me for this late response...

To-day :

k = 23451 is up to 1,677,664 base two, no prime, continuing...

k = 60849 is up to 1,501,350 base two, no prime, continuing...

I also have a first assessment about our chance of proving the base 4 Sierpinski conjecture :

it is about 8.6*10^-5 in the present range (f20, n = 1,048,576 to 2,097,150)

and about 4.5*10^-4 in the next range (f21, n = 2,097,152 to 4,194,302)

but the number of remaining primes to be found is expected to be 8 by this calculus, while it is really 4, so, I think these assessments are pessimistic!

"Que sera sera..."

Jean

[Citrix]

Some

What are our chances of finding 1 prime in this range. (n<2M)?
If the chances are close to 0, should we stop the work?
Do we need more sieving, does anyone know how long it takes to find a factor?
Should we p-1 instead of sieve?
Should Mystwalker (if willing) PRP instead of sieve/p-1?
Till where will we have to PRP to finish the problem?


Thanks

[tcadigan]

since Jean just updated his stats....I'll update the files again.

dat drop from 75 kb to 67 kb

[Jean Penné]

I think I can only respond to the 1) and 2) questions by Citrix :

1) For the 4 k values remaining, I can estimate the probability to find a prime in the present n range, and in the next n ranges, starting from the present one :

kvalue : 18534 23451 60849 64494

to 2^21 : 0.08 0.24 0.28 0.20
to 2^22 : 0.16 0.43 0.48 0.36
to 2^23 : 0.23 0.57 0.63 0.49
to 2^24 : 0.29 0.67 0.73 0.59
to 2^25 : 0.35 0.75 0.80 0.67
to 2^26 : 0.40 0.81 0.86 0.74

I could continue, but we are now above the 10 million digits candidates!

2) We have NO reason to be discouraged : These probabilities are not so small, and we are very lucky because of having still only 4 primes to found!
Comparing to SoB project, I see they are already in the 2^23 to 2^24 range, and with still 8 primes to found, the next beeing expected to have 19 millions digits!

Here are the formulas I am using for these estimates :

The expected number of primes found in the range N1 to N2 is :

P(k,N1,N2) = w(k)/2log(2)*log[(2N1+log2(k))/(2N2+log2(k))]

w(k) beeing the weight of k (the weight computed with small n's and small prime divisors, not the Nash-Jobling weight).
This is the formula by Yves Gallot, adapted to base 4 (I did'nt need to translate it, the expected frequencies beeing not too bad when compared to the experimental values).

And the chance to find a prime in the range is 1-exp(-P) admitting a Poisson law...

Good luck for this project, and Best Regards,
Jean

[Jean Penné]

In my previous post, would you read :

The expected number of primes found in the range N1 to N2 is :

P(k,N1,N2) = w(k)/2log(2)*log[(2*N2+log2(k))/(2*N1+log2(k))]

Sorry for the error...

Jean

[Mystwalker]

Thanks for the sieving instructions, everyone!
I will start sieving someone this week, depending on when my PSP sieve ranges are complete.

@Citrix:
I think the question sieve vs. PRP should once again be very influenced by the processor architecture. In my case, this will be a Core Duo*, so I'm not sure whoch one is the better technical alternative. But as all k's are currently assigned, I think that, organisatorically, sieving is the better way.

*By the way:
Which of the sr2sieve versions (for Windows) will perform best on this CPU?

[geoff]

Originally Posted by Mystwalker

In my case, this will be a Core Duo*

*By the way:
Which of the sr2sieve versions (for Windows) will perform best on this CPU?

The -pentium4 build probably, lacking a way to compile the -k8 build for Windows.

I am testing some improvements to the sr2sieve code that should make it 20% faster for this project (from 415 kp/s to 500 kp/s on my P2/400). If it works out they will be in version 1.4.20.

[Mystwalker]

The P4 build is ~1% faster than i686 and ~2% faster than i586 - according to quick benchmarking, probably not enough for such a small deviation.

I could do some sieving, but I'm not sure whether it is efficient for such a small n range (~500K). With the expected probabilities for primes with n<2M, we might discuss increasing the sieving range. But with only 4 k's left, it's of course difficult to find an optimal range...


Btw.:

K 	Weight 	At 2^	Testing up to 2^	Reserved by
18534	92	1500000                         Citrix
23451	230	1677664      2000000            Jean Penne
60849	263     1501350      2000000            Jean Penne  
64494	93	1470458                         tcadigan
66741	0 	~~~~~~~~~BASE 4 SIERPINSKI NUMBER~~~~~~~~~	

Total Weight = 678
Average Weight= 169.5

Sieving Completed (Billions): 0-7500

[tcadigan]

Originally Posted by Mystwalker

The P4 build is ~1% faster than i686 and ~2% faster than i586 - according to quick benchmarking, probably not enough for such a small deviation.

I could do some sieving, but I'm not sure whether it is efficient for such a small n range (~500K). With the expected probabilities for primes with n<2M, we might discuss increasing the sieving range. But with only 4 k's left, it's of course difficult to find an optimal range...

for my 2 cents....I've thought about bumping to 5 million. I wouldn't be opposed to the 2^23 limit either

sure the probabilities don't increase a whole lot, but we're starting to get to pretty big numbers if we do find a prime. I agree with you that it might not be worth a whole lot to sieve for the last .5M

I was sieving with JJSieve and went until I was finding factors there as as fast as I was eliminating them with LLR....now with geoff's sieve sieving rates drastically improved (for me). I stick with this project because it's pretty low maintenance and it sucks up the cycles while ggnfs is running concurrently.