about computing zeta'(s) in the critical strip
David Bernier
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 .
Speiser [1934]:
http://www.aimath.org/WWN/rh/articles/html/89a/
There's a paper by Garaev and Yildirim, available in
it's pre-print form here:
http://arxiv.org/abs/math/0610377v2
"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
Raymond Manzoni
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>
Yitang Zhang(2001) "On the zeros of zeta'(s) near the critical line"
<http://eduunix.ccut.edu.cn/index2/math/202.38.126.65/mathdoc/Duke.Mathematical.Journal/DMJ11003_4.pdf>
Some references provided in these papers could be interesting too.
Hoping it helped a little,
Raymond
Marko Amnell
Maybe Michael Rubinstein's L-function software will work.
The default L-function is the Riemann zeta function.
http://pmmac03.math.uwaterloo.ca/~mrubinst/L_function_public/L.html
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."
Raymond Manzoni
> 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.
>
> Some references provided in these papers could be interesting too.
For example :
Levinson+Montgomery(1974) "Zeros of the derivatives of the Riemann
zeta-function" :
<http://www.kryakin.com/files/Acta_Mat_(2_55)/acta150_107/133/133_03.pdf>
Conrey+Ghosh(1990?) "Zeros of derivatives of the Riemann
zeta-function near the critical line"
<http://books.google.fr/books?hl=fr&lr=&id=G02moOmuOX4C&oi=fnd&pg=PA95>
Mezzadri(2002) "Random matrix theory and the zeros of zeta'(s)" (with
numerical investigations) : <http://arxiv.org/pdf/math-ph/0207044>
Saidak(2004) "On the logarithmic derivative of the Euler product"
<http://tatra.mat.savba.sk/Full/29/14SAIDAK.ps>
>
> 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
Axel Vogt
> Raymond Manzoni a écrit :
>> David Bernier a écrit :
Here 'are' some using Maple's command RootFinding[Analytic]:
.964685622705685650525780+48.8471599050684790854189*I
.848735328105403472052794+60.1408457820384239102073*I
.864622864426113300262053+76.3628078964670422358770*I
.780628004724644645328179+95.2929682713522169397106*I
.864103640598939499604406+88.1775174098810128722274*I
.856309339180055369726490+134.193836602386409228846*I
.943828539659771481951279+140.469959838197100688840*I
.662929906884329935358395+150.485953620246866996388*I
.966951342073371224843721+156.632667913413661808966*I
.863404697829980428874710+158.282522106715305651649*I
.635638410195870078269381+111.431017613746736506374*I
.847766864212029839013393+123.715269749934938660387*I
Raymond Manzoni
> Raymond Manzoni wrote:
>> Raymond Manzoni a �crit :
>>> David Bernier a �crit :
Nice! (my method was rather primitive...)
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)
Fine continuation!
Raymond
David Bernier
> "Raymond Manzoni" <ray...@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 .
>>>
>>> Speiser [1934]:
>> 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>
>>
>> Yitang Zhang(2001) "On the zeros of zeta'(s) near the critical line"
>> <http://eduunix.ccut.edu.cn/index2/math/202.38.126.65/mathdoc/Duke.Mathematical.Journal/DMJ11003_4.pdf>
>>
>> Some references provided in these papers could be interesting too.
>> Hoping it helped a little,
>> Raymond
>
> Maybe Michael Rubinstein's L-function software will work.
> The default L-function is the Riemann zeta function.
>
> http://pmmac03.math.uwaterloo.ca/~mrubinst/L_function_public/L.html
>
> 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'.
For the point s = 0.848735 + 60.140846*I,
I get:
bash$ ./lcalc -d 2 -v -x 0.848735 -y 60.140846
1.082 0.1029
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:
bash$ ./lcalc -d 1 -v -x .84873530 -y 60.140845702
3.830269e-08 4.274359e-08 .
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.
A link to a web page about the Argument Principle:
http://mathworld.wolfram.com/ArgumentPrinciple.html
David Bernier
David Bernier
[...]
> Below I give the smallest value of | zeta'(.)| I found
> near s = 0.848735 + 60.140846*I:
>
> bash$ ./lcalc -d 1 -v -x .84873530 -y 60.140845702
> 3.830269e-08 4.274359e-08 .
>
> In other words,
> zeta'(.8487353 + 60.140845702*I) ~= 0.00000004 + 0.00000004*I .
[...]
Using PARI-gp I get further:
? (zeta(%62) - zeta(%62+delta))/delta
%65 = 1.2715731464878770130 E-11 + 4.321841984664728360 E-11*I
[derivative is very close to zero.]
? delta
%66 = 1.0000000000000000000000000000000000000 E-20
? %62
%67 = 0.84873532809000000000000000000000000000 +
60.140845782000000000000000000000000000*I
"%62" is the value on output-line number 62.
So zeta'(0.84873532809 + 60.140845782) ~= 0.
David Bernier
P.S. 60.140845782 is close to a local maximum of the
Riemann-Siegel Z(.) function, or
RiemannSiegelZ in Mathematica.
David Bernier
Thanks additionally to Axel Vogt for the Maple computations.
The Riemann-Siegel Z function has a local minimum of -0.37 near t = 357.58.
I used Glen Pugh's Z-plotter to get this:
http://web.viu.ca/pughg/RiemannZeta/RiemannZetaLong.html
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 .
After some time, I got:
? (zeta(%158 + 0.5 E-100) - zeta(%158 - 0.5 E-100))/(1.0 E-100)
%160 = -2.0529131546 E-34 -1.2558044177 E-34*I
? %158
%161 = 0.67492445948651172431513544516762825 +
357.57576692022870053439669037496992465*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. 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 .
From reading the hypothesis in Theorem 3 of Yitang Zhang's
2001 Duke Math. J. paper, with a link given by
Raymond Manzoni being:
<http://eduunix.ccut.edu.cn/index2/math/202.38.126.65/mathdoc/Duke.Mathematical.Journal/DMJ11003_4.pdf>
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 .
David Bernier
David Bernier
This shows how one can accomplish the Newton iterative
method in PARI-gp: (for zeros of zeta')
%260 =
0.6159808652502243493441636295353630657935035232448022488850729948269200791600256469641388865822549070137942004625719591011444230932177007267705602939894378662566389476923435368427843967727976391216951517185305197348740676202437164879272912758855253667222428085147212409839813104516038844796851234321862426867417817534892046203133140476723510770506360409986523342535643727111436606614765236499423448487471861937818613282790249
+
185.2148123380504146026425868511807419367212456480013948970148740216439300819187581741693854389755434384956306427043055798877540530353880256171226710432704095174963732037243371458921372890739297231783479305479533665778338291236880768737749098457172586794949781316306785440490560424572325866953672145777350570622113387706746854837345900402663385674113926542553588966611225125836137545595347755103003717274167383786845386256705*I
? %260 -((zeta(%260+delta/2) - zeta(%260 - delta/2))/delta)/(((zeta(%260
+delta)-zeta(%260 ))/delta - (zeta(%260)-zeta(%260 - delta))/delta)/delta)
%261 =
0.61598086525022434934416362953536306579350352324480224888507299482692007916002564696413888658225490701379420046257195910114442309321767826762906274075509372456689106277299810
+
185.2148123380504146026425868511807419367212456480013948970148740216439300819187581741693854389755434384956306427043055798877540530353880210435451071431276191243312226292493623396089602295715887*I
(zeta(%261+0.0000000000000000000001)-zeta(%261-0.0000000000000000000001))/0.0000000000000000000002
%263 =
-2.0409330487129462454206541839119844680858556152243312780461944519282797989677857007170548820578865077668292759767906
E-44 +
1.1397362696963610746730853441636642275298134490298296710634666816089367900687222909370492667688224267939387852905115
E-44*I
? delta
%264 =
1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
E-200
The basic iterative step in Newton's method to
locate a zero of zeta' is:
? %260 -((zeta(%260+delta/2) - zeta(%260 - delta/2))/
delta)/(((zeta(%260 +delta)-zeta(%260 ))/delta -
(zeta(%260)-zeta(%260 - delta))/delta)/delta) [ENTER]
-->
%261 [a number]
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
Raymond Manzoni
(snip)
>>
>> Thanks additionally to Axel Vogt for the Maple computations.
>>
>> The Riemann-Siegel Z function has a local minimum of -0.37 near t =
>> 357.58.
>> I used Glen Pugh's Z-plotter to get this:
>> http://web.viu.ca/pughg/RiemannZeta/RiemannZetaLong.html
>>
Another (possibly more confusing) applet is available on Matthew
Watkins' site about zeta :
<http://www.secamlocal.ex.ac.uk/people/staff/mrwatkin//zeta/CSExplorer/CSExplorer.htm>
(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 .
>>
>> After some time, I got:
>>
>>
>> ? (zeta(%158 + 0.5 E-100) - zeta(%158 - 0.5 E-100))/(1.0 E-100)
>> %160 = -2.0529131546 E-34 -1.2558044177 E-34*I
>> ? %158
>> %161 = 0.67492445948651172431513544516762825 +
>> 357.57576692022870053439669037496992465*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.
Some of these points (search 'Lehmer's Phenomenon') are provided in
Edwards' excellent book about zeta :
<http://books.google.com/books?id=5uLAoued_dIC&pg=PA179>
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
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!
Pleasant Explorations!
Raymond
(*) Script I used in pari/gp <http://pari.math.u-bordeaux.fr/download.html>
eps=1e-40;
\p 200
zetap(x)=(zeta(x+eps/2)-zeta(x-eps/2))/eps;
zetas(x)=(zeta(x+eps/2)-2*zeta(x)+zeta(x-eps/2))/eps^2;
fn(x)=x-zetap(x)/zetas(x)
fs(x)=r=x-zetap(x)*(x-xp)/(zetap(x)-zetap(xp));xp=x;r
xp=0.5+17143.8*I
fn(%)
fs(precision(%,200))
(iterating the last line until 'division by zero' ;-))
(iterating fn alone (Newton-Raphson) didn't converge most of the time...)
David Bernier
For the probable zero of zeta' you found, I get the approximation:
s~= 0.500616733706738943604893700414+17143.8042162726985158817223566*I
Then, 1/(Re(s) - 1/2) ~= 1621.445 .
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
[...]
David Bernier
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.
David Bernier
[...]
> 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:
Cf.:
http://en.wikipedia.org/wiki/Z_function
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.]
David Bernier
David Bernier
[...]
> 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.
David Bernier
David Bernier
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.
? %2
0.500000252347038803 + 18882503.901568975845293608*I (A)
? %20
0.50000025235197704296 + 18882503.90156897584828762548*I (B)
zeta''(%2) ~= 62.035774 - 38.815900*I (C)
David Bernier
Raymond Manzoni
(snip)
>
>
> s~= 0.500616733706738943604893700414+17143.8042162726985158817223566*I
>
> Then, 1/(Re(s) - 1/2) ~= 1621.445 .
>
> 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
Perhaps that some recent papers of Nathan Ng could interest you :
<http://arxiv.org/find/math/1/au:+Ng_N/0/1/0/all/0/1>
especially his discussion in "Extreme values of zeta prime rho"
See too Garaev's "On small distances between ordinates of zeros of
zeta(s) and zeta'(s)"
<http://www.math.boun.edu.tr/instructors/yildirim/paper/OnSmallDistancesBtwOrdinates.pdf>
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).
For an implementation see Ken Takusagawa's "Tabulating values of the
Riemann-Siegel Z function along the critical line" :
<http://web.mit.edu/kenta/www/six/parallel/2-Final-Report.html>
see too Tuck's "Riemann-Siegel sums via stationary phase"
<https://www.austms.org.au/Publ/Bulletin/V72P2/pdf/722-5212-Tuck-v.pdf>
Regards,
Raymond
David Bernier
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].
Cf.:
< http://www.dtc.umn.edu/~odlyzko/doc/cnt.html > , 10th paper or so ...
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:
Cf.:
< http://www.shoup.net/ntl/ >
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.
----
In the article
http://sci.tech-archive.net/Archive/sci.math/2009-10/msg02124.html ,
I was wondering if Z(t) having no negative local maximum when t>100
& Z(t) having no positive local minimum when t>100
was enough to imply the Riemann Hypothesis.
In the problem statement of RH at ClayMath, Bombieri mentions
an RH equivalent:
"The Riemann hypothesis is equivalent to the statement that
all local maxima of xi(t) are positive and
all local minima are negative, [...] "
Cf.:
< http://www.claymath.org/millennium/Riemann_Hypothesis/ >
---> Official Problem Description, page 6 of 11.
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 ...
Regards,
David Bernier
David Bernier
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
Dave Seaman
> 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
Third Circuit ignores precedent in Mumia Abu-Jamal ruling.
<http://www.indybay.org/newsitems/2008/03/29/18489281.php>
David Bernier
> 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/>
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.
I uploaded the output here:
< http://berniermath.net/mp90quadrature.txt >
The CPU times mean nothing, as I disabled timing.
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 ...
David Bernier
David Bernier
> 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/>
I installed GMP and it was quite easy. It is easy to do
multi-precision basic arithmetic; certainly +, - , * and '/' .
Maybe also sqrt...
But I didn't find a multi-precision log function, sine or cosine
functions.
There are C++ libraries that can work in standalone or in
coordination with GMP and have transcendental multi-precision
functions.
One I tried is CLN (Class Library for Numbers):
< http://www.ginac.de/CLN/cln.html#SEC_Top >
One problem for me is my unfamiliarity with C++ : classes,
input/output , etc. Also, the "make and Makefile" do
their best to build everything right and put lib...so.6 in
the right place. But my g++ compiler only found
lib...so.6 after I put it in /usr/lib64 .
[my computer has an x86_64 architecture ].
For now, I'm going back to PARI-gp and the Euler-Maclaurin
formula.
To check on accuracy of C arithmetic with "long floats",
I did the sum (for t = 388858886.0023394051)
sum_{n = 1 ... 10^9} cos(t*log(n))/sqrt(n) (***)
both in C with long floats and with pari-gp:
bash$ ./a.out
Main term:
t= 388858886.002339405094971880 sigma = 0.5000 :
real_part = 0.000081980021093364, ( C result for (***))
term1_real = 0.000080353148421926 // other term in E.M.
term2_real = -0.000002433374635325 // other term in E.M.
term3_real = 0.000001012524886827 // other term in E.M.
term4_real = 0.000000002551752271 // other term in E.M.
PARI-gp gives, for the main term, (***)
0.0000819799059123200468 [ result A ]
So the C program is off by 1.15 E-10 .
That's too large to locate zeros of zeta' within
about 1.0 E-8 (or better), I think.
As for timing, PARI-gp returned "result A" in
one or two hours, which seems Ok if I just want
to locate the probable zero of zeta' near
0.5 + i*388858886.0023394051 .
David Bernier
David Bernier
[...]
> For now, I'm going back to PARI-gp and the Euler-Maclaurin
> formula.
>
> To check on accuracy of C arithmetic with "long floats",
> I did the sum (for t = 388858886.0023394051)
>
> sum_{n = 1 ... 10^9} cos(t*log(n))/sqrt(n) (***)
> both in C with long floats and with pari-gp:
>
> bash$ ./a.out
> Main term:
> t= 388858886.002339405094971880 sigma = 0.5000 :
>
> real_part = 0.000081980021093364, ( C result for (***))
>
>
> term1_real = 0.000080353148421926 // other term in E.M.
> term2_real = -0.000002433374635325 // other term in E.M.
> term3_real = 0.000001012524886827 // other term in E.M.
> term4_real = 0.000000002551752271 // other term in E.M.
>
> PARI-gp gives, for the main term, (***)
>
> 0.0000819799059123200468 [ result A ]
>
> So the C program is off by 1.15 E-10 .
>
> That's too large to locate zeros of zeta' within
> about 1.0 E-8 (or better), I think.
>
> As for timing, PARI-gp returned "result A" in
> one or two hours, which seems Ok if I just want
> to locate the probable zero of zeta' near
> 0.5 + i*388858886.0023394051 .
Using formula (1) in section 6.4 of Edwards
(2nd printing, 1974; unabridged republication by Dover, 2001),
with N = 10^9 + 1, and up to the B_14 term where
B_14 = 7/6 (Bernoulli numbers), I get
zeta(0.5 + 388858886.0023394051*i) ~=
0.00000507521799042249 + 0.00002463889615635353*i.
I got the "Lehmer pair" of zeros from:
Csordas, Odlyzko, Smith and Varga;
"A new Lehmer pair of zeros and a new lower
bound for the de Bruijn-Newman constant Lambda",
Electronic Transactions on Numerical Analysis, vol. 1,
pp. 104-111, Dec. 1993.
By averaging the two zeros in the Lehmer pair, we
get s = 0.5 + 388858886.0023394051 as above.
David Bernier
David Bernier
There were some mistakes ...
I've tried to reconcile Euler-Mac. for N = 10^9 + 1 with the value for
N = 2*10^9 + 1.
Now I get zeta(0.5 + 388858886.0023394051*i) ~=
//for N = 10^9 + 1
0.00000020846871558245436915586964904969378368 +
0.000000075820596896391683884239455999894392459*I
// for N = 2*10^9 + 1
0.00000020846871558245437662886707468701281518 +
0.000000075820596896391682720123370911320226157*I