"On small distances between ordinates of zeros of zeta(s) and zeta'(s)" which seems like it could be a good source for previous results on the zeros of zeta' and how they relate to the zeros of zeta, in the critical strip.
Or else, maybe someone has already computed some of the zeros of zeta' in the critical strip, but I didn't find anything like that.
> "On small distances between ordinates of zeros of zeta(s) and zeta'(s)" > which seems like it could be a good source for previous results > on the zeros of zeta' and how they relate to the zeros of zeta, > in the critical strip.
> Or else, maybe someone has already computed some of the zeros > of zeta' in the critical strip, but I didn't find anything like > that.
> David Bernier
Two recent papers :
Haseo Ki(2008) "The zeros of the derivative of the Riemann zeta function near the critical line" <http://arxiv.org/pdf/math/0701726>
"Raymond Manzoni" <raym...@free.fr> wrote: > David Bernier a écrit : >> I'm interested in methods for computing the derivative of the >> Riemann zeta function, zeta', in the critical strip >> 0<= Re(s) <= 1.
>> One of the equivalents of the Riemann Hypothesis is >> that zeta' has no zero s with 0 < Re(s) < 1/2 .
>> "On small distances between ordinates of zeros of zeta(s) and zeta'(s)" >> which seems like it could be a good source for previous results >> on the zeros of zeta' and how they relate to the zeros of zeta, >> in the critical strip.
>> Or else, maybe someone has already computed some of the zeros >> of zeta' in the critical strip, but I didn't find anything like >> that.
>> David Bernier
> Two recent papers :
> Haseo Ki(2008) "The zeros of the derivative of the Riemann zeta function > near the critical line" <http://arxiv.org/pdf/math/0701726>
There's an option for computing derivatives about which the Readme file says:
"Presently the derivative option uses numeric differentiation, and one loses about half the working precision for each successive derivative. Multiprecision is still being implemented, so, for now, the derivative option only gives moderately reasonable output for the first derivative (about 6-7 digits), and less for the second derivative (about 3 digits). Beyond this, one needs to use the USE_LONG_DOUBLE compile option in the MAkefile or higher precision."
> David Bernier a écrit : >> I'm interested in methods for computing the derivative of the >> Riemann zeta function, zeta', in the critical strip >> 0<= Re(s) <= 1.
(snip)
> Some references provided in these papers could be interesting too.
> > Or else, maybe someone has already computed some of the zeros > of zeta' in the critical strip, but I didn't find anything like > that.
I tried a numerical search (using pari/gp) and found two zeros of zeta' around these values (may be...) : 0.96468562270568565 + 48.847159905068479085*I 0.864623222098647 + 76.362807896467*I
Raymond Manzoni wrote: > Raymond Manzoni a écrit : >> David Bernier a écrit : >>> I'm interested in methods for computing the derivative of the >>> Riemann zeta function, zeta', in the critical strip >>> 0<= Re(s) <= 1. > (snip)
>> Some references provided in these papers could be interesting too.
> > Or else, maybe someone has already computed some of the zeros > > of zeta' in the critical strip, but I didn't find anything like > > that.
> I tried a numerical search (using pari/gp) and found two zeros of > zeta' around these values (may be...) : > 0.96468562270568565 + 48.847159905068479085*I > 0.864623222098647 + 76.362807896467*I
> Hoping it helped, > Raymond
Here 'are' some using Maple's command RootFinding[Analytic]:
> Raymond Manzoni wrote: >> Raymond Manzoni a écrit : >>> David Bernier a écrit : >>>> I'm interested in methods for computing the derivative of the >>>> Riemann zeta function, zeta', in the critical strip >>>> 0<= Re(s) <= 1. >> (snip)
>>> Some references provided in these papers could be interesting too.
>> > Or else, maybe someone has already computed some of the zeros >> > of zeta' in the critical strip, but I didn't find anything like >> > that.
>> I tried a numerical search (using pari/gp) and found two zeros of >> zeta' around these values (may be...) : >> 0.96468562270568565 + 48.847159905068479085*I >> 0.864623222098647 + 76.362807896467*I
>> Hoping it helped, >> Raymond
> Here 'are' some using Maple's command RootFinding[Analytic]:
To the OP note that the zeta function has more zeros in the same imaginary range so that I'll add some zeros with real part larger than 1 : 2.46316186945432128587439505331+23.2983204927628579020109616266i 1.28649682226904769704411427839+31.7082500831159086049543521423i 1.38276360571167457578453372043+42.2909645545967298190807460934i (using this time the secant method on pari/gp)
Marko Amnell wrote: > "Raymond Manzoni" <raym...@free.fr> wrote: >> David Bernier a écrit : >>> I'm interested in methods for computing the derivative of the >>> Riemann zeta function, zeta', in the critical strip >>> 0<= Re(s) <= 1.
>>> One of the equivalents of the Riemann Hypothesis is >>> that zeta' has no zero s with 0 < Re(s) < 1/2 .
> There's an option for computing derivatives about which the Readme file > says:
> "Presently the derivative option uses numeric differentiation, and one > loses about half the working precision for each successive derivative. > Multiprecision is still being implemented, so, for now, the derivative > option > only gives moderately reasonable output for the first derivative (about 6-7 > digits), > and less for the second derivative (about 3 digits). Beyond this, one > needs to use the USE_LONG_DOUBLE compile option in the MAkefile or higher > precision."
Thanks to Raymond Manzoni and Marko Amnell for the useful information.
I've been experimenting with Michael Rubinstein's lcalc command-line program.
For locating probable zeros of zeta', I've found that knowing zeta'' is useful, once one is near a probable zero of zeta'.
which means zeta''(s) ~= 1.082 + 0.1029*I . By using the approximation zeta''(s) ~~= 1 and Newton's method, it's quite easy to get closer and closer to a probable zero of zeta' near s.
Below I give the smallest value of | zeta'(.)| I found near s = 0.848735 + 60.140846*I:
In other words, zeta'(.8487353 + 60.140845702*I) ~= 0.00000004 + 0.00000004*I .
I haven't done so, but I think one could use the Argument principle and numerically integrate zeta''/zeta' in a small (but not too small) square or rectangle around the probable zero to show that the square or rectangle really does contain a zero of zeta' . I might try that with a square of side about 0.001.
So for s = 0.6749244594865117 + 357.5757669202287005*I, zeta'(s) ~= 0 .
PARI-gp has the advantage of being able to do complex arithmetic, and also stores the output of each command-line computation as %n, where n --> the numeral for line number n, e.g. %2 for output from line 2.
I searched for more points where Z(t) has a local extremum whose value (in absolute value) is quite small. If there are zeros of zeta' close by, I wasn't able to find them with the limited methods and tools I have, i.e. using lcalc at one point and PARI-gp.
A local minimum of Z(t) near t = 376.079 attains about Z(t) = -0.19 .
Another local minimum of Z(t) is for Z(946.222) ~= -0.081 .
it could be that zeros of zeta' with real part close to 0.5 tend to occur near a pair of very close zeros of zeta; this would correspond to very close zeros of the Z(t) function. Also, in order to find zeros of zeta' with with real part as close as possible to 0.5, it seems reasonable to search for very close zeros of Z(t), as I believe I read that Z(t_0) = 0 and Z'(t_0) = 0 implies that zeta has a double (or higher...) zero at 1/2 + i*t_0 .
> So for s = 0.6749244594865117 + 357.5757669202287005*I, > zeta'(s) ~= 0 .
> PARI-gp has the advantage of being able to do > complex arithmetic, and also stores the output > of each command-line computation as %n, where > n --> the numeral for line number n, e.g. > %2 for output from line 2.
> I searched for more points where Z(t) has a local > extremum whose value (in absolute value) is > quite small. If there are zeros of zeta' close by, > I wasn't able to find them with the limited methods and tools > I have, i.e. using lcalc at one point and PARI-gp.
> A local minimum of Z(t) near > t = 376.079 attains about Z(t) = -0.19 .
> Another local minimum of Z(t) is > for Z(946.222) ~= -0.081 .
> it could be that zeros of zeta' with real part close to 0.5 > tend to occur near a pair of very close zeros of zeta; > this would correspond to very close zeros of the Z(t) > function. Also, in order to find zeros of zeta' > with with real part as close as possible to 0.5, > it seems reasonable to search for very close zeros > of Z(t), as I believe I read that > Z(t_0) = 0 and Z'(t_0) = 0 implies that zeta has > a double (or higher...) zero at 1/2 + i*t_0 .
This shows how one can accomplish the Newton iterative method in PARI-gp: (for zeros of zeta')
Above, %260 should be close enough to a zero of zeta' so that the iterations converge.
Then, replace %260 by %261 in the long line after the question mark above.
I eventually get "division by zero". PARI-gp "plays" with the significant figures or something. Appending many 0s to the real part, then the Imaginary part and combining as: a + b*I seems to restore more significant digits.
Another (possibly more confusing) applet is available on Matthew Watkins' site about zeta : <http://www.secamlocal.ex.ac.uk/people/staff/mrwatkin//zeta/CSExplorer...> (select Riemann Siegel at the bottom left, choose the Y offset and... try to avoid using the scrollbar at the bottom or you'll get out of the critical line, lose the fast Riemann-Siegel evaluation and have to be patient... ;-))
>> So for s = 0.6749244594865117 + 357.5757669202287005*I, >> zeta'(s) ~= 0 .
>> PARI-gp has the advantage of being able to do >> complex arithmetic, and also stores the output >> of each command-line computation as %n, where >> n --> the numeral for line number n, e.g. >> %2 for output from line 2.
>> I searched for more points where Z(t) has a local >> extremum whose value (in absolute value) is >> quite small.
Example : for t ~= 17143.8039 the maximum is around 0.002153 using the secant method (*) I found that zeta'(0.5006167337067389436048937 + 17143.804216272698515881722i) was nearly 0
>> it could be that zeros of zeta' with real part close to 0.5 >> tend to occur near a pair of very close zeros of zeta; >> this would correspond to very close zeros of the Z(t) >> function. Also, in order to find zeros of zeta' >> with with real part as close as possible to 0.5, >> it seems reasonable to search for very close zeros >> of Z(t), as I believe I read that >> Z(t_0) = 0 and Z'(t_0) = 0 implies that zeta has >> a double (or higher...) zero at 1/2 + i*t_0 .
> This shows how one can accomplish the Newton iterative > method in PARI-gp: (for zeros of zeta')
> Above, %260 should be close enough to a zero of zeta' so that > the iterations converge.
> Then, replace %260 by %261 in the long line after the question mark > above.
> I eventually get "division by zero". PARI-gp "plays" with the > significant figures or something. Appending many 0s > to the real part, then the Imaginary part and combining > as: a + b*I seems to restore more significant digits.
> David Bernier
Yes pari/gp will remove the non-significative digits so that, for example, if you evaluate zetap(z)= (zeta(z+eps/2)-zeta(z-eps/2))/eps at a point z such that zeta'(z)=0 you'll lose nearly -log_10(eps) digits (every time!).
A useful trick is to 'force' the default precision by replacing zetap(z) with zetap(precision(z,default(realprecision)))
(by the way in a script default(realprecision, n) allows too to change the default precision to n)
You'll still get "division by zero" at the end but probably because you were subtracting two equal values at the denominator!
> (select Riemann Siegel at the bottom left, choose the Y offset and... > try to avoid using the scrollbar at the bottom or you'll get out of the > critical line, lose the fast Riemann-Siegel evaluation and have to be > patient... ;-))
>>> A local minimum of Z(t) where the absolute value of the minimum attained >>> is about 0.37 is quite small, for t ~ 357 .
>>> Using lcalc and PARI-gp, I searched for a zero of zeta' >>> near s = 0.5 + 357.58*I .
>>> So for s = 0.6749244594865117 + 357.5757669202287005*I, >>> zeta'(s) ~= 0 .
>>> PARI-gp has the advantage of being able to do >>> complex arithmetic, and also stores the output >>> of each command-line computation as %n, where >>> n --> the numeral for line number n, e.g. >>> %2 for output from line 2.
>>> I searched for more points where Z(t) has a local >>> extremum whose value (in absolute value) is >>> quite small.
> Example : for t ~= 17143.8039 the maximum is around 0.002153 > using the secant method (*) I found that > zeta'(0.5006167337067389436048937 + 17143.804216272698515881722i) was > nearly 0
For the probable zero of zeta' you found, I get the approximation:
I wonder if there are conjectures or guesses as to the true asymptotics of (Re(s) - 1/2) in terms of Im(s), for zeros s = beta' + gamma' of zeta', where gamma' > 0 and letting gamma' become arbitrarily large ...
Thanks for the info. on the behaviour of PARI-gp with respect to significant digits in computations , left unsnipped below.
> Yes pari/gp will remove the non-significative digits so that, for > example, if you evaluate zetap(z)= (zeta(z+eps/2)-zeta(z-eps/2))/eps > at a point z such that zeta'(z)=0 you'll lose nearly -log_10(eps) > digits (every time!).
> A useful trick is to 'force' the default precision by replacing > zetap(z) with zetap(precision(z,default(realprecision)))
> (by the way in a script default(realprecision, n) allows too to > change the default precision to n)
> You'll still get "division by zero" at the end but probably because > you were subtracting two equal values at the denominator!
>> (select Riemann Siegel at the bottom left, choose the Y offset >> and... try to avoid using the scrollbar at the bottom or you'll get >> out of the critical line, lose the fast Riemann-Siegel evaluation and >> have to be patient... ;-))
>>>> A local minimum of Z(t) where the absolute value of the minimum >>>> attained >>>> is about 0.37 is quite small, for t ~ 357 .
>>>> Using lcalc and PARI-gp, I searched for a zero of zeta' >>>> near s = 0.5 + 357.58*I .
>>>> So for s = 0.6749244594865117 + 357.5757669202287005*I, >>>> zeta'(s) ~= 0 .
>>>> PARI-gp has the advantage of being able to do >>>> complex arithmetic, and also stores the output >>>> of each command-line computation as %n, where >>>> n --> the numeral for line number n, e.g. >>>> %2 for output from line 2.
>>>> I searched for more points where Z(t) has a local >>>> extremum whose value (in absolute value) is >>>> quite small.
Richard Brent mentioned a "Lehmer pair" in his 1979 article about verifying RH for the first 75,000,000 non-trivial zeros.
As I understand it, with n = 41,820,581 the pair of zeros is the n'th and the (n+1)st, where he found that max_{t from Im(rho_n) to Im(rho_{n+1})} |Z(t)| < 0.00000248 .
[ rho_n is the n'th non-trivial zero].
I believe this is for t ~= 18882503.9 , and using a C program with Euler-MacLaurin summation, I find that Z attains between Im(rho_n) and Im(rho_{n+1}) about as follows:
>> Example : for t ~= 17143.8039 the maximum is around 0.002153 >> using the secant method (*) I found that >> zeta'(0.5006167337067389436048937 + 17143.804216272698515881722i) was >> nearly 0
> For the probable zero of zeta' you found, I get the approximation:
> I wonder if there are conjectures or guesses as to the true > asymptotics of > (Re(s) - 1/2) in terms of Im(s), for zeros s = beta' + gamma' > of zeta', where gamma' > 0 and letting gamma' become > arbitrarily large ...
> Thanks for the info. on the behaviour of PARI-gp with > respect to significant digits in computations , left > unsnipped below.
> David Bernier
> [...]
>> Yes pari/gp will remove the non-significative digits so that, for >> example, if you evaluate zetap(z)= (zeta(z+eps/2)-zeta(z-eps/2))/eps >> at a point z such that zeta'(z)=0 you'll lose nearly -log_10(eps) >> digits (every time!).
>> A useful trick is to 'force' the default precision by replacing >> zetap(z) with zetap(precision(z,default(realprecision)))
>> (by the way in a script default(realprecision, n) allows too to >> change the default precision to n)
>> You'll still get "division by zero" at the end but probably because >> you were subtracting two equal values at the denominator!
> Richard Brent mentioned a "Lehmer pair" in his 1979 article about > verifying RH for the first 75,000,000 non-trivial zeros.
> As I understand it, with n = 41,820,581 the pair of zeros is the n'th > and the (n+1)st, where he found that > max_{t from Im(rho_n) to Im(rho_{n+1})} |Z(t)| < 0.00000248 .
> [ rho_n is the n'th non-trivial zero].
> I believe this is for t ~= 18882503.9 , > and using a C program with Euler-MacLaurin summation, > I find that Z attains between Im(rho_n) and Im(rho_{n+1}) > about as follows:
> Z(18882503.90157) ~= 0.000002476
> which is in line with Brent's results.
[...]
I have 'lcalc' pre-compiled, as distributed by M. Rubinstein. This uses 64-bit doubles, I believe. As for PARI-gp, evaluating zeta(sigma +i*t) for t ~= 18882503.9 takes a lot of time (maybe an hour or so). One result returned by PARI-gp is this: ? zeta(0.5000227046 + 18882503.90177114*I) %1 = 0.00000102513240401800620447999232271568910311260563490669721490611 - 0.000000247134107511231289945163352238926148478404827421149565046384*I
Euler-Maclaurin summation for zeta is described in Section 6.4 of Edwards' book, and programming it for evaluating zeta(sigma +i*t) is just a bit more work than programming it for evaluating zeta(1/2 +i*t).
Some compiled languages have a 'long double' floating point type, with more significant bits than a 'double' type.
Perhaps | zeta'| is small at the point 1/2 +i*t where t satisfies Z'(t) = 0, and t is in between two zeros of Z(.) corresponding to a Lehmer pair:
zeta(1/2 + i*t) = exp(-i theta(t)) Z(t), then zeta'(1/2 + i*t) = .... [ the problem lies in trying to take or taking complex derivatives of the continuations of exp(-i theta(t)) and Z(t), if they exist in some neighborhood.]
> I have 'lcalc' pre-compiled, as distributed by M. Rubinstein. This uses
I was wrong about compilation. After unzipping and re-creating the archived files and directories, the source code is compiled after one gives the 'make' command.
>>> (select Riemann Siegel at the bottom left, choose the Y offset >>> and... try to avoid using the scrollbar at the bottom or you'll get >>> out of the critical line, lose the fast Riemann-Siegel evaluation and >>> have to be patient... ;-))
>>>>> A local minimum of Z(t) where the absolute value of the minimum >>>>> attained >>>>> is about 0.37 is quite small, for t ~ 357 .
>>>>> Using lcalc and PARI-gp, I searched for a zero of zeta' >>>>> near s = 0.5 + 357.58*I .
>>>>> So for s = 0.6749244594865117 + 357.5757669202287005*I, >>>>> zeta'(s) ~= 0 .
>>>>> PARI-gp has the advantage of being able to do >>>>> complex arithmetic, and also stores the output >>>>> of each command-line computation as %n, where >>>>> n --> the numeral for line number n, e.g. >>>>> %2 for output from line 2.
>>>>> I searched for more points where Z(t) has a local >>>>> extremum whose value (in absolute value) is >>>>> quite small.
> Richard Brent mentioned a "Lehmer pair" in his 1979 article about > verifying RH for the first 75,000,000 non-trivial zeros.
> As I understand it, with n = 41,820,581 the pair of zeros is the n'th > and the (n+1)st, where he found that > max_{t from Im(rho_n) to Im(rho_{n+1})} |Z(t)| < 0.00000248 .
> [ rho_n is the n'th non-trivial zero].
> I believe this is for t ~= 18882503.9 , > and using a C program with Euler-MacLaurin summation, > I find that Z attains between Im(rho_n) and Im(rho_{n+1}) > about as follows:
> Z(18882503.90157) ~= 0.000002476
> which is in line with Brent's results.
[...]
In the Newton-Raphson method, the value (A) (or %2) below was my starting point as an approximation to a zero of zeta' . Using finite difference quotients, I got the approximation to the second derivative of zeta, at A, which appears in (C) below.
I also had an approximation to zeta' at A [not shown]. So applying finite differences Newton's method to the approximate probable zero in (A) [ for the function zeta' ] , one step led to (B) below, which differs from (A) in absolute value by about 6 E-12 . The approximation (B) to a probable zero of zeta' should be better than approximation (A), if all went well.
I used PARI-gp, and each zeta evaluation seemed to take an hour or two, if not more.
> I wonder if there are conjectures or guesses as to the true > asymptotics of > (Re(s) - 1/2) in terms of Im(s), for zeros s = beta' + gamma' > of zeta', where gamma' > 0 and letting gamma' become > arbitrarily large ...
> Thanks for the info. on the behaviour of PARI-gp with > respect to significant digits in computations , left > unsnipped below.
Concerning fast evaluation of Riemann zeta you may look at Hiary's "Fast methods to compute the Riemann zeta function" and references provided there : <http://fr.arxiv.org/abs/0711.5005v1>
Euler MacLaurin is easy to implement but requires evaluation of about t terms (t= Im(s)) of the partial zeta sum. I think it is often used to find the small zeros with high precision (and probably in pari/gp...). Riemann-Siegel is not very accurate for small values of t but pretty good for large values since needing only around sqrt(t/(2 pi)) terms of the zeta sum. Both methods are described in the Edwards book even if Riemann-Siegel is harder to implement (the error term is the hard part!) and restricted there to the case Re(s)= 1/2. The two applets referenced use R-S on the critical line (I think it could be implemented for Re(s)<>1).
>> I wonder if there are conjectures or guesses as to the true >> asymptotics of >> (Re(s) - 1/2) in terms of Im(s), for zeros s = beta' + gamma' >> of zeta', where gamma' > 0 and letting gamma' become >> arbitrarily large ...
>> Thanks for the info. on the behaviour of PARI-gp with >> respect to significant digits in computations , left >> unsnipped below.
> Concerning fast evaluation of Riemann zeta you may look at Hiary's > "Fast methods to compute the Riemann zeta function" and references > provided there : <http://fr.arxiv.org/abs/0711.5005v1>
> Euler MacLaurin is easy to implement but requires evaluation of about > t terms (t= Im(s)) of the partial zeta sum. I think it is often used to > find the small zeros with high precision (and probably in pari/gp...). > Riemann-Siegel is not very accurate for small values of t but pretty > good for large values since needing only around sqrt(t/(2 pi)) terms of > the zeta sum.
For now, I'm interested mostly in numerical approximation of zeros beta' + i*gamma' of the derivative of Riemann zeta, with beta' very close to 1/2. Empirically, good places to start seem to include the vicinity of Lehmer pairs.
For the Lehmer pair with imaginary part ~= 17143.8, PARI-gp took perhaps 2 or 3 hours per 38-digit zeta computation at a height t ~= 17143.8.
Moving on to the Lehmer pair with imaginary parts about 388,588,886 mentioned in Odlyzko et al, the zeta computations become more time-consuming if one wants 12+ digits accuracy.
"A New Lehmer pair of zeros and a new lower bound for the de Bruijn-Newman constant LAMBDA" [1993] authors: G. Csordas, A. M. Odlyzko, W. Smith, and R. S. Varga.
That was based on "by-products" of RH verification for hundreds of millions of non-trivial zeros in the 1980's by the Dutch, e.g. LRW86: http://en.wikipedia.org/wiki/Riemann_hypothesis#Numerical_calculations [ Australian R. Brent is linked to J. van de Lune, H. J. J. te Riele, D. T. Winter via RH verification before 1986].
The Lehmer pair appears there as t = 3.888 588 860 022 851 203 e+08, t = 3.888 588 860 023 936 899 e+08
equivalent to t = 388,858,886.0022851203 and t = 388,858,886.0023936899 .
PARI-gp's built-in zeta(.) can probably do the zeta evaluations, but the time it took for a Lehmer pair with t ~= 18,000,000 (about 3 hours) doesn't bode well for t ~= 388,858,886.002.
It seems to me that for numerical computation of zeros of zeta', a lot of accuracy in the zeta function values is desirable, since zeta varies slowly near a zero of zeta' such as the one with imaginary part about 18,000,000 . I think this argues for Euler-Maclaurin summation. Even "long doubles" seem to give only about 11 or 12 decimal digits (after the decimal point) for the two zeta zeros at height ~= 388,858,886.02 .
One workable option is to sum 1 billion or so terms in PARI-gp of both cos(t log(n))/sqrt(n) [n = 1 ... 10^9] and sin(t log(n))/sqrt(n) [n = 1 ... 10^9] and add a few terms in the Euler-Maclaurin expansion, in the PARI-gp environment.
I've done the 1 billion cosine partial sum, and it took a few hours.
Another possibility for 20 decimal+ zeta evaluations is through the use of Victor Shoup's NTL library:
So far, I've been able to gunzip the *.gz file, extract the *.tar archive, run ./configure [ default] , 'make', and 'make check' [ Tests Ok ]. Then, 'make install' as root: # make install .
Next, I'd want to write a program that uses NTL to do simple transcendental function computations using "quad_floats", which offer 106-bit precision.
> Both methods are described in the Edwards book even if Riemann-Siegel > is harder to implement (the error term is the hard part!) and restricted > there to the case Re(s)= 1/2. The two applets referenced use R-S on the > critical line (I think it could be implemented for Re(s)<>1).
Since for the time being I just want to compute zeta' zeros which are or could be near a few selected Lehmer pairs of zeros, I find Euler-Maclaurin summation more appealing than the Riemann-Siegel formula.
Starting from: "all local maxima of xi(t) are positive and all local minima are negative"
I've been thinking about relations with: "Z(t) has no negative local maximum when t>100 & Z(t) has no positive local minimum when t>100"
I know well that the average of |Z(t)| grows slowly as t>0 increases. I don't know xi(t) so well, however if the average value of |xi(t)| near t changes fast as the point on the critical line corresponding to t moves up the line Im(s) = 1/2, perhaps one can't rule out "all local maxima of xi(t) are positive and all local minima are negative" Failing, while "Z(t) has no negative local maximum when t>100 & Z(t) has no positive local minimum when t>100" might still Hold ...
I'd be rather interested in knowing if: Z(t) has no negative local maximum when t>100 & Z(t) has no positive local minimum when t>100" implies RH ...
>>> I wonder if there are conjectures or guesses as to the true >>> asymptotics of >>> (Re(s) - 1/2) in terms of Im(s), for zeros s = beta' + gamma' >>> of zeta', where gamma' > 0 and letting gamma' become >>> arbitrarily large ...
>>> Thanks for the info. on the behaviour of PARI-gp with >>> respect to significant digits in computations , left >>> unsnipped below.
>> Concerning fast evaluation of Riemann zeta you may look at Hiary's >> "Fast methods to compute the Riemann zeta function" and references >> provided there : <http://fr.arxiv.org/abs/0711.5005v1>
>> Euler MacLaurin is easy to implement but requires evaluation of >> about t terms (t= Im(s)) of the partial zeta sum. I think it is often >> used to find the small zeros with high precision (and probably in >> pari/gp...). >> Riemann-Siegel is not very accurate for small values of t but pretty >> good for large values since needing only around sqrt(t/(2 pi)) terms >> of the zeta sum.
> For now, I'm interested mostly in numerical approximation of zeros > beta' + i*gamma' of the derivative of Riemann zeta, with > beta' very close to 1/2. Empirically, good places to start > seem to include the vicinity of Lehmer pairs.
> For the Lehmer pair with imaginary part ~= 17143.8, PARI-gp > took perhaps 2 or 3 hours per 38-digit zeta computation at > a height t ~= 17143.8.
> Moving on to the Lehmer pair with imaginary parts > about 388,588,886 mentioned in Odlyzko et al, the > zeta computations become more time-consuming if > one wants 12+ digits accuracy.
> "A New Lehmer pair of zeros and a new lower bound for the de > Bruijn-Newman constant LAMBDA" [1993] > authors: G. Csordas, A. M. Odlyzko, W. Smith, and R. S. Varga.
> That was based on "by-products" of RH verification for hundreds > of millions of non-trivial zeros in the 1980's by the Dutch, > e.g. > LRW86: > http://en.wikipedia.org/wiki/Riemann_hypothesis#Numerical_calculations > [ Australian R. Brent is linked to J. van de Lune, H. J. J. te Riele, D. > T. Winter via RH verification before 1986].
> The Lehmer pair appears there as > t = 3.888 588 860 022 851 203 e+08, > t = 3.888 588 860 023 936 899 e+08
> equivalent to > t = 388,858,886.0022851203 and > t = 388,858,886.0023936899 .
> PARI-gp's built-in zeta(.) can probably do the zeta evaluations, but > the time it took for a Lehmer pair with t ~= 18,000,000 (about 3 hours) > doesn't bode well for t ~= 388,858,886.002.
> It seems to me that for numerical computation of zeros of zeta', > a lot of accuracy in the zeta function values is desirable, since > zeta varies slowly near a zero of zeta' such as the one > with imaginary part about 18,000,000 . I think this argues for > Euler-Maclaurin summation. Even "long doubles" seem to give > only about 11 or 12 decimal digits (after the decimal point) > for the two zeta zeros at height ~= 388,858,886.02 .
> One workable option is to sum 1 billion or so terms in > PARI-gp of both cos(t log(n))/sqrt(n) [n = 1 ... 10^9] > and sin(t log(n))/sqrt(n) [n = 1 ... 10^9] > and add a few terms in the Euler-Maclaurin expansion, > in the PARI-gp environment.
> I've done the 1 billion cosine partial sum, and it took a few hours.
> Another possibility for 20 decimal+ zeta evaluations is through > the use of Victor Shoup's NTL library:
> So far, I've been able to gunzip the *.gz file, extract the *.tar > archive, run ./configure [ default] , 'make', and 'make check' > [ Tests Ok ]. Then, 'make install' as root: # make install .
> Next, I'd want to write a program that uses NTL to do simple > transcendental function computations using "quad_floats", > which offer 106-bit precision.
[...]
I don't know much about C++, and I didn't find sample code with commented examples that really helped me.
David Bailey and others have developed MPFUN90 and other Fortran or C++ libraries for high-precision arithmetic, and I'll probably experiment with one of the libraries some time.
On Fri, 13 Nov 2009 21:17:34 -0500, David Bernier wrote: > I don't know much about C++, and I didn't find sample code > with commented examples that really helped me. > David Bailey and others have developed MPFUN90 and other > Fortran or C++ libraries for high-precision arithmetic, > and I'll probably experiment with one of the libraries > some time. > Link to David Bailey web page: >< http://crd.lbl.gov/~dhbailey/mpdist/ > > David Bernier
GMP is an extended-precision library that can be used with C or C++. It claims to be faster than any other bignum library. <http://gmplib.org/>
Dave Seaman wrote: > On Fri, 13 Nov 2009 21:17:34 -0500, David Bernier wrote:
>> I don't know much about C++, and I didn't find sample code >> with commented examples that really helped me.
>> David Bailey and others have developed MPFUN90 and other >> Fortran or C++ libraries for high-precision arithmetic, >> and I'll probably experiment with one of the libraries >> some time.
> GMP is an extended-precision library that can be used with C or C++. > It claims to be faster than any other bignum library. > <http://gmplib.org/>
Thanks. I downloaded mpfun90.tar.gz from David Bailey's web site. Unzipping and extracting the archive went without a problem. As building, I changed the name of the Fortran compiler to "gfortran", I think, and removed any calls to timing functions. Since I also tried the ARPREC package, it could be something like removing calls to "etime" for mpfun90, and calls to "second()" for the ARPREC package.
The problem I had with ARPREC was getting the "includes" right for my own programs.
For mpfun90, I was able to run test programs that get built when one does "make" [ this uses what's in the furnished Makefile ].
One of these is the executable quadts, which does 15 numerical integration problems. I'm quite impressed: about 400D precision except Problem 15 (something not quite right there) in a few minutes.
So I'm thinking about getting the right compiler options for mpfun90, for my own source code. AFAIK, the executable _quadts_ was built using directives, such as those in the Makefile.
Perhaps there's a "verbose" option with GNU make, so that I could see what the compiler options were when building _quadts_ or other included test programs ...
|
