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"
<vdstrat@a...> 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<p,c++;x=nextprime(x+1));c
>
> 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
>
>
>
>
> Unsubscribe by an email to: primenumbers-unsubscribe@yahoogroups.com
> The Prime Pages : http://www.primepages.org/
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/