Conference rusure::math

    What about   sum(n=1..oo) 1/n^p   for p>3
    
    do we know anything about them? i.e do we have a value for this sum?
    we know that for p=3, it is not known, does that mean for all p>= 3 it
    is also not known?
    
    /nasser

    I asked about this, all even sums are known, i.e any 
    sum(n=1..oo) 1/n^p  where p is even is known.

       N   sum(1/j^N) very approximately (i.e., BASIC single precision)
    
       2   1.64473	Pi^2/6
       3   1.20205	Pi^3/25.8
       4   1.08232	Pi^4/90
       5   1.03693	Pi^5/295
       6   1.01734	Pi^6/945
       7   1.00835	Pi^7/2995
       8   1.00408	Pi^8/9450
       9   1.00201	...
    
    On this tissue of evidence I conjecture that
    
    	IF R[2k] is defined by:  sum(n=1..oo) 1/n^p = R[2k]*Pi^2k,
    
    	THEN R[2k+1] = SQRT(R[2k]*R[2k+2]).
    
      John
    
    dictated but not spell-checked :-)

    >   5   1.03693	Pi^5/295
    you get the 295 offcourse by doing  Pi^5/1.03693, and approximate
    to it. 
    the problem I think is that we dont know if the multiplier of
    Pi^N (when N is odd is rational or irrational), I think that is
    the problem here.

    can you see a pattern for the odd N's multipliers? 

    the values for even N can all be obtained anlytically exactly
    the formula is (for even N's):
                                          2k
                                    (2 Pi)
            sum(n=1..oo) 1/n^2k = ---------- | B_2k |
                                    2 (2K)!

    the books says, this holds for all natural numbers K, where B_2k are
    the Bernoulli numbers. (you can see if your even N results matches the
    above formula).

    will talk more on this later..

    /Nasser
    I spell checked (almost)

    FWIW,
    
        Sum 1/(n^k)  n = 1 ... infinity
    
    equals the Riemann zeta function with argument k.
    
    Perhaps there exist efficient routines for calculating the Riemann zeta
    function?
    
        -- Jeff

    You're asking for zeta(3) which is known to be irrational, but
    it is not known if it is made up of any simple relation involving
    pi or not.

    You can evaluate the sum accurately with Euler Maclurin summation
    by basically thinking of the sum as a trapezoidal rule approx to
    an integral and expressing the error comitted as an asymptotic
    expansion involving the odd order derivatives at the endpoints
    of summation.  Maple would do this for you without your having
    to even think about it, but I don't have access to it right now.

    People have evaluated numerous continued fraction convergants of
    this in the hopes of finding gold there...

    - Jim

(This reply has been re-entered to fix an integration error that no self-
respecting schoolchild would have made. Sigh...)

Given this is a historic unsolved problem, I don't expect we can contribute
much to a formal solution. BUT, we've got a tool that Riemann and Hilbert
never had, i.e. computers, which we can maybe use to come up with some
intelligent conjectures...

An example of the Obvious Brute Force approach for Sum(n=1...inf)(1/n�) is:

1) Evaluate Sum(n=1...M)(1/n�) to a gazillion digits for large M
2) Divide by PI�, again to a gazillion digits
3) Examine the result for the appearence of repeating decimal sequences, which
   would indicate a rational number, and form the appropriate conjecture.

The problem with the OBF approach is that 1/n� converges very slowly, so most
of our gazillion digits are bogus. So, an interesting subproblem here that we
MIGHT be able to contribute to is, how can you accelerate the convergence of
Sum(n=1...M)(1/n�)?

Here's a couple of feeble attempts...

1)	Sum(all n>0)(1/n�) is equal to Product(all prime p>1) (1/(1-1/p�)).
	So, if you had fast gazillion-digit Ln and Exp routines, you could
	get a better approximation, as the K'th term of the log of this product
	is approximately 1/(K*lnK)� which converges faster - but not much!

2)	Since 1/x� is monotonically decreasing as x->inf,

	Integral(x=K...inf)(1/x� dx)
		    < Sum(n=K...inf) (1/n^3)
				< Integral(x=K...inf)(1/(x-1)^3 dx)

	Or,
	    1/2K� < Sum(n=K...inf) (1/n^3) < 1/2(K-1)�


	Or,
	    Approx(K) < Sum(n=1...inf)(1/n�) < Approx(K) + (2K-1)/(2K�(K-1)�)
		where Approx(K) = Sum(n=1...K)(1/n�) + 1/2(K-1)�

	The error term is < 1/(K-1)�, which is pretty good - it means, for
	instance, that we can get 18-digit accuracy from 1,000,000 terms
	of the sum (using >25-digit arithmetic). I believe that if you "split
	the difference" between the two integrals above, i.e.
		Approx(K) = Sum(n=1...K)(1/n�) + 1/2(K-�)�,
	the absolute value of the error (which can be positive or negative now)
	becomes < 1/K^4, but I can't prove it yet...

Here's a proof (with some algebraic manipulation eliminated) that for n > 1,
 Integral(x=n...inf)(1/(x-�)� dx) - Sum(k=n...inf)(1/k�) < 1/8(n-�)^4 

1)	if Y(k) = Integral(x=k...k+1)(1/(x-�)� dx), Y(k) = k/(k�-�)�

2)	k/(k�-�)� > k/k^4 = 1/k� so Y(k) > 1/k�

3)	if Z(k) = Integral(x=k...k+1) (1/2(x-�)^5 dx), Z(k) = (4k�+k)/8(k�-�)^4

4)	(4k�+k)/8(k�-�)^4 > 4k�/8(k�-�)^4 = k�/2(k�-�)^4 so Z(k) > k�/2(k�-�)^4 

5)	Y(k)-Z(k) < k/(k�-�)� - k�/2(k�-�)^4 = k/(k�-�)�(1-k�/2(k�-�)�)
 
6)	1-k�/2(k�-�)� < 1-k�/2k^4 = 1-1/2k� < (1-1/4k�)� = (k�-�)/k^4, so

7)	Y(k)-Z(k) < (k/(k�-�))*((k�-�)/k^4) = 1/k�

Now we can use the results from (2) and (7) and sum over k to get 

Sum(n=k...inf) (Y(k)-Z(k)) < Sum(n=k...inf)(1/k�) < Sum(n=k...inf) (Y(k))

Which gives us the result we want, since

	Sum(n=k...inf)Z(k) = Integral(x=k...inf)(1/2(x-�)^5 dx) = 1/8(n-�)^4

This means that Sum(n=1...1000000)(1/n�) + 2/1999999� should be within
1.3*10^-25 of Sum(n=1...inf)(1/n�), or about 25 digits accuracy, if computed
with > 33 digit precision.

Anyone have a BIGNUM package and some computer time?
							Richie

> Anyone have a BIGNUM package and some computer time?
    
    I just picked up the MP package from note 26.6 and will soon be making
    good use (VAX 9000-400) of Approx(K) to verify my earlier conjecture. :-)
    
      John

Well, if you'er going to invest all that time, the least I can do is fix the
other dumb error in my formulae, namely I believe I counted 1/k� twice when
I spliced the finite and infinite sum together; the "real" Approx(K) is:

		Approx(K) = Sum(n=1...K)(1/n�) + 1/2(K+�)�

(and this appears to check out, according to DECALC, which shows Approx(K)
converging as rapidly as expected; Approx(2000) = 1.20205690315960 is accurate
to 12-14 places after the decimal point, depending on what floating point 
format DECALC uses...)

							Richie