Prime numbers and primality testing Yahoo Group TR: [PrimeNumbers] pi(x) =============================================== Didier van der Straten Message 1 of 2 Aug 29, 2003 ----------------------------------------------- Sorry I failed to "reply to all" in my previous post. So I didn't see my message posted. I also introduced a few corrections. Rgds. Didier van der Straten -----Message d'origine----- De : Didier van der Straten [mailto:vdstrat@...] Envoyé : mercredi 27 août 2003 21:42 À : Jon Perry Objet : RE: [PrimeNumbers] pi(x) About 3 years ago, I undertook a detailed study of this "difference" between the "expected" prime count and the "actual" prime count, using for the "expected" one exactly that formula proposed as "epc". The relative error (p-e)/p becomes positive and slightly increasing. The absolute error increases continuously to the point that one might effectively challenge the probality rpc. That steady difference stems from fact that one should develop the product rpc into the the sum of its terms, then compute epc, and for each resulting term take the "integer" part of the division of the studied interval prime(n) -> prime(n+1)^2 - 1 by the denominator of that term, to compute exactly the count of composite numbers being multiples of this denominator (instead of the actual quotient). This creates each time a small delta and one might expect that the algebric sum of all those delta would vanish to nothing. Summing up (algebrically) all those partial differences leads actually to a substantial value which explains why the expected count of primes becomes consistenly higher than the actual count. In a near future I intend to develop pages on my site about this interesting question. Encouragements are expected. Please see already my initiating summary at http://www.geocities.com/dhvanderstraten/sumaspi.html Rgds Didier van der Straten -----Message d'origine----- De : Jon Perry [mailto:perry@...] Envoyé : mercredi 27 août 2003 14:31 À : Primeform@Yahoogroups. Com; Prime Numbers Objet : [PrimeNumbers] pi(x) Can anyone point out where this goes wrong? \p10 rpc(n)=prod(i=1,n,1-1.0/prime(i)) epc(n)=(prime(n+1)^2-1-prime(n))*rpc(n) rpc(n) is the product of (1-1/p) for the first n primes. As this gives the probability of an integer x being prime, epc(n) considers the range [(p_n)+1, (p_n+1)^2-1], and multiplies it by rpc(n). e.g. rpc(4)=1/2*2/3*4/5*6/7=0.2285714285 p_4 is 7 and p_5=11, so the range is [8,120], which contains 113 integers. So the expected prime count is 113*0.2285714285=25.82857142. Using; pcf(n)=local(c,x,p);c=0;x=nextprime(prime(n)+1);p=prime(n+1)^2-1;while (x "(p-e)/p)) 32.83116883 : 34 -> 0.03437738731 147.2068119 : 152 -> 0.03153413203 383.1007038 : 394 -> 0.02766318817 671.9602034 : 685 -> 0.01903619939 1215.685902 : 1227 -> 0.009220942984 1838.156993 : 1847 -> 0.004787767598 2505.717169 : 2512 -> 0.002501126839 3417.597653 : 3396 -> -0.006359733172 4114.540437 : 4119 -> 0.001082680797 5516.150124 : 5472 -> -0.008068370759 6888.637611 : 6814 -> -0.01095356785 7832.284712 : 7782 -> -0.006461669521 9668.926109 : 9566 -> -0.01075957652 11815.97295 : 11631 -> -0.01590344357 13723.67436 : 13491 -> -0.01724663558 16222.40953 : 15873 -> -0.02201282285 17925.08431 : 17593 -> -0.01887593462 19703.97596 : 19361 -> -0.01771478566 22627.35464 : 22187 -> -0.01984741701 26506.75028 : 25836 -> -0.02596184732 where the final number is the relative error (does this tends to 0?). Anyway, my main point is that I can't see why this doesn't work with 100% accuracy. Jon Perry perry@... http://www.users.globalnet.co.uk/~perry/maths/ http://www.users.globalnet.co.uk/~perry/DIVMenu/ BrainBench MVP for HTML and JavaScript http://www.brainbench.com =============================================== Mark Underwood Message 2 of 2 Aug 30, 2003 ----------------------------------------------- Hi Didier I just read some of your material from your webpage. You said, "The study proceeds actually in two steps : (1) Find a 'good' formula for the decay of the prime density in two consecutive intervals between the squares of consecutive prime numbers. (2) See how good this formula can remain when replacing those 'squares of prime numbers' by 'squares of approximated prime numbers. " I wish you the best of success in that endeavour, please let us know your findings. Just for fun, here's something that caught my eye recently: The number of primes between the primes of successive odd numbers: between 1^2 and 3^2 : 4 primes between 3^2 and 5^2 : 5 primes between 5^2 and 7^2 : 6 primes between 7^2 and 9^2 : 7 primes between 9^2 and 11^2: 8 primes between 11^2 and 13^2: 9 primes Then of course after this it all falls apart! I have come to expect that kind of thing from primes by now :) Mark --- In primenumbers@yahoogroups.com, "Didier van der Straten" wrote: > Sorry I failed to "reply to all" in my previous post. > So I didn't see my message posted. > > I also introduced a few corrections. > Rgds. > Didier van der Straten > > -----Message d'origine----- > De : Didier van der Straten [mailto:vdstrat@a...] > Envoyé : mercredi 27 août 2003 21:42 > À : Jon Perry > Objet : RE: [PrimeNumbers] pi(x) > > > About 3 years ago, I undertook a detailed study of this "difference" between > the "expected" prime count and the "actual" prime count, using > for the "expected" one exactly that formula proposed as "epc". The relative > error (p-e)/p becomes positive and slightly increasing. The absolute > error increases continuously to the point that one might effectively > challenge the probality rpc. > > That steady difference stems from fact that one should develop the product > rpc into the the sum of its terms, then compute epc, and for each resulting > term take the "integer" part of the division of the studied interval > prime(n) -> prime(n+1)^2 - 1 by the denominator of that term, to compute > exactly the count of composite numbers being multiples of this denominator > (instead of the actual quotient). This creates each time a small delta and > one might expect that the algebric sum of all those delta would vanish to > nothing. Summing up (algebrically) all those partial differences leads > actually to a substantial value which explains why the expected count of > primes becomes consistenly higher than the actual count. > > In a near future I intend to develop pages on my site about this interesting > question. Encouragements are expected. Please see already my initiating > summary at http://www.geocities.com/dhvanderstraten/sumaspi.html > > Rgds > Didier van der Straten > > -----Message d'origine----- > De : Jon Perry [mailto:perry@g...] > Envoyé : mercredi 27 août 2003 14:31 > À : Primeform@Yahoogroups. Com; Prime Numbers > Objet : [PrimeNumbers] pi(x) > > > Can anyone point out where this goes wrong? > > \p10 > rpc(n)=prod(i=1,n,1-1.0/prime(i)) > epc(n)=(prime(n+1)^2-1-prime(n))*rpc(n) > > rpc(n) is the product of (1-1/p) for the first n primes. As this gives the > probability of an integer x being prime, epc(n) considers the range > [(p_n)+1, (p_n+1)^2-1], and multiplies it by rpc(n). > > e.g. rpc(4)=1/2*2/3*4/5*6/7=0.2285714285 > > p_4 is 7 and p_5=11, so the range is [8,120], which contains 113 integers. > > So the expected prime count is 113*0.2285714285=25.82857142. > > Using; > > pcf(n)=local(c,x,p);c=0;x=nextprime(prime(n)+1);p=prime(n+1)^2- 1;while > (x > to determine the actual number of primes in this region gives 26, so the > estimate seems spot on. > > Testing over a larger range; > > ? forstep(i=5,100,5,e=epc(i);p=pcf(i);print(e" : "p" -> "(p-e)/p)) > 32.83116883 : 34 -> 0.03437738731 > 147.2068119 : 152 -> 0.03153413203 > 383.1007038 : 394 -> 0.02766318817 > 671.9602034 : 685 -> 0.01903619939 > 1215.685902 : 1227 -> 0.009220942984 > 1838.156993 : 1847 -> 0.004787767598 > 2505.717169 : 2512 -> 0.002501126839 > 3417.597653 : 3396 -> -0.006359733172 > 4114.540437 : 4119 -> 0.001082680797 > 5516.150124 : 5472 -> -0.008068370759 > 6888.637611 : 6814 -> -0.01095356785 > 7832.284712 : 7782 -> -0.006461669521 > 9668.926109 : 9566 -> -0.01075957652 > 11815.97295 : 11631 -> -0.01590344357 > 13723.67436 : 13491 -> -0.01724663558 > 16222.40953 : 15873 -> -0.02201282285 > 17925.08431 : 17593 -> -0.01887593462 > 19703.97596 : 19361 -> -0.01771478566 > 22627.35464 : 22187 -> -0.01984741701 > 26506.75028 : 25836 -> -0.02596184732 > > where the final number is the relative error (does this tends to 0?). > > Anyway, my main point is that I can't see why this doesn't work with 100% > accuracy. > > Jon Perry > perry@g... > http://www.users.globalnet.co.uk/~perry/maths/ > http://www.users.globalnet.co.uk/~perry/DIVMenu/ > BrainBench MVP for HTML and JavaScript > http://www.brainbench.com =============================================== Cached by Georg Fischer at Nov 14 2019 12:46 with clean_yahoo.pl V1.4