This is the fourth “research” thread of the Polymath15 project to upper bound the de Bruijn-Newman constant , continuing https://terrytao.wordpress.com/2018/01/24/polymath-proposal-upper-bounding-the-de-bruijn-newman-constant/. Progress will be summarised at this Polymath wiki page.

We are getting closer to finishing off the following test problem: can one show that whenever , ? This would morally show that . A wiki page for this problem has now been created here. We have obtained a number of approximations to (see wiki page), though numeric evidence indicates that the approximations are all very close to each other. (Many of these approximations come with a correction term , but thus far it seems that we may be able to avoid having to use this refinement to the approximations.) The effective approximation also comes with an effective error bound

for some explicit (but somewhat messy) error terms : see this wiki page for details. The original approximations can be considered deprecated at this point in favour of the (slightly more complicated) approximation ; the approximation is a simplified version of which is not quite as accurate but might be useful for testing purposes.

It is convenient to normalise everything by an explicit non-zero factor . Asymptotically, converges to 1; numerically, it appears that its magnitude (and also its real part) stays roughly between 0.4 and 3 in the range , and we seem to be able to keep it (or at least the toy counterpart ) away from zero starting from about (here it seems that there is a useful trick of multiplying by Euler-type factors like to cancel off some of the oscillation). Also, the bounds on the error seem to be of size about 0.1 or better in these ranges also. So we seem to be on track to be able to rigorously eliminate zeroes starting from about or so. We have not discussed too much what to do with the small values of ; at some point our effective error bounds will become unusable, and we may have to find some more faster ways to compute .

In addition to this main direction of inquiry, there have been additional discussions on the dynamics of zeroes, and some numerical investigations of the behaviour Lehmer pairs under heat flow. Contributors are welcome to summarise any findings from these discussions from previous threads (or on any other related topic, e.g. improvements in the code) in the comments below.

### Like this:

Like Loading...

## 105 comments

Comments feed for this article

24 February, 2018 at 10:25 am

Terence TaoA note that some of the phases and exponents in the toy approximation were not quite correct in the previous post, but are now correct on the wiki (here it was very helpful by the way to have numerics for all the other approximations as this was very effective at detecting these inaccuracies). The expression now takes the form

for some explicit but probably not very important phase . To make this non-zero it suffices to show that

where is a slight shift of . This is basically the same problem as before except for a very tiny shift in the parameter. In particular the trick of multiplying by factors such as should still be useful (a key point being that this factor also produces a bit of cancellation on the RHS as well as the LHS, albeit to a lesser extent due to the mismatch in the term of the exponent).

24 February, 2018 at 2:54 pm

Terence TaoTo set some explicit benchmarks, I think a good roadmap would be the following:

Goal 1. Show that is non-vanishing for any (or maybe say to exclude any pathologies at small coming from the inaccurate nature of the approximation).

Goal 2. Show that is non-vanishing for any (or , etc.)

Goal 3. Show that for all decently large , one can lower bound by (this will solve the test problem for sufficiently large , something additional will have to be done when is so small that the approximation is no longer effectively accurate).

My guess is that once we figure out how to efficiently achieve Goal 1, Goal 2 would be doable by a slight modification of the method, and Goal 3 would then also be relatively straightforward (of course we have to become better at controlling the errors for this).

As mentioned above, to establish Goal 1 it suffices to establish the inequality

for all in the range of interest, where and . Some thoughts on this:

(a) The variable keeps jumping with at square multiples of . However, we may be able to get away with rounding down to the nearest multiple of (say) 100 and treating the error by the triangle inequality. This creates significantly fewer jumps and we can start using the fundamental theorem of calculus (bounding the derivative of the expressions inside the absolute values) between each pair of jumps. Another minor side benefit of decreasing is that it may also improve slightly the bound on the derivative (the large terms are a bit more oscillatory than the small terms).

(b) As before we can try to multiply both sides by Euler factors like to have less oscillation (this may help reduce the upper bound on the derivative).

(c) If we have an upper bound on the derivative then we can try to use that to sample adaptively, rather than using a worst-case mesh, as this may lead to some useful speedup. For instance, suppose numerically ranges between 0.4 and 3 and has a derivative that can be provably upper bounded by 5 (these numbers are made up for sake of argument). Then we could be conservative and sample for in an equally spaced mesh of size , and as long as the ratio always evaluates to be greater than 0.4 on this mesh, we are OK for Goal 1. But if for instance at some value of x this ratio evaluates to be larger, say 2.1, then we can skip ahead to rather than since that is the first place where a zero could conceivably occur. There are variants of this strategy where we evaluate the first derivative at the mesh point and use some upper bound on the second derivative, together with a Taylor expansion with remainder, to try to get an even larger skip, but perhaps just a first derivative analysis will already give a sufficient speedup for our purposes.

24 February, 2018 at 5:36 pm

Terence TaoOn further thought I think (a) is not going to give significant speedups. The intervals on which is constant are so much larger than the mesh sizes we are considering that there is little to gain by concatenating them into even larger intervals, so one may as well treat each such interval separately. Even for up to , only goes up to about 1784, and the cost of doing 1784 individual calculations would be trivial compared against the total number of mesh points one has to work with.

The other thing is that one does not have to work on the above goals sequentially; it is also possible for instance for some participants to work on understanding the error terms even before say Goal 1 is completed. Also I am beginning to suspect that the error analysis may not be sufficient to handle medium values of x, such as , and one may indeed need to revive the “C” term in the type approximations in order to obtain a significantly better error term, as suggested in previous comments, to handle this range.

25 February, 2018 at 6:20 pm

David Bernier (@doubledeckerpot)I thought of multiplying the sumands on the LHS of inequality 2 by:

1 =

to render denominators in sums on LHS and RHS equal (I think).

25 February, 2018 at 7:44 pm

Anonymousthis idea of using equal denominators is also mentioned in https://terrytao.wordpress.com/2018/02/24/polymath15-fourth-thread-closing-in-on-the-test-problem/#comment-493119

24 February, 2018 at 1:29 pm

David Bernier (@doubledeckerpot)For , I get a pretty good agreement with the tables

when I take a with imaginary part 0.4, as shown

below:

? B0(10^3 + 0.4*I)

= 3.4426 E-167 + 3.5411 E-167*I

? B0(10^4 + 0.4*I)

= -1.1850 E-1700 – 7.7879 E-1700*I

? B0(10^5 + 0.4*I)

= -7.6133 E-17047 + 2.5066 E-17047*I

So I suppose is .

24 February, 2018 at 2:35 pm

Terence TaoYes, throughout that wiki page it is assumed that . Thanks for checking against the tables, it is always good to have independent confirmation to guard against errors.

24 February, 2018 at 2:15 pm

AnonymousIs it possible to exploit also some (perhaps crude) information on the asymptotics of the phases of the dominant parts of and the error term (not merely their magnitudes) to improve on the triangle inequality ?

24 February, 2018 at 2:40 pm

Terence TaoMy feeling is that we will not be able to get much out of this, because and oscillate in opposite directions (they are sort of conjugate to each other), and so one will periodically run into situations in which the triangle inequality is best possible. A caricature of the situation would be if we had and where were fairly slowly varying (note that the toy approximations are basically of this form, assuming that the small components of the sum dominate, as they seem to do numerically). If one wanted to keep away from zero, it would suffice to show that for all . On the other hand, if there was an interval of moderate length (e.g. a unit interval) on which one instead had , then would wind around the origin a non-trivial number of times, and so by the argument principle one should expect to have a zero of for some .

24 February, 2018 at 3:08 pm

AnonymousIn the wiki page on the test problem, is defined in the first approach (and its modification) without the square root.

[Corrected, thanks – T.]24 February, 2018 at 6:10 pm

AnonymousAnother possibility for fast simulteneous(!) computation of and the bound on the error term on a large grid, is to use ideas from Platt’s paper on a (high precision) FFT-based method (with rigorous bounds).

24 February, 2018 at 7:08 pm

Terence TaoIt does seem that the trick of multiplying by an Euler factor also produces a moderate improvement in the derivative bounds.

Recall that we are trying to prove a bound of the form for all , where

, . Let us pick a value of , so that ranges in the interval . I picked for sake of discussion, as this gives the interval that contains . On this interval, the triangle inequality gives the bounds

which is not quite enough to make the term of dominate since . We have the derivative bounds

so the quantity fluctuates at a rate of at most , and one could design a mesh (either fixed-spacing or adaptive) to explore the interval accordingly.

Now suppose we transform the inequality to the equivalent inequality , where

A brief computation shows that

The same triangle inequality analysis as before gives the bounds

so in fact now is bounded away from zero (it is at least ) and oscillates at rate at most , thus we have removed a bit of the oscillation from by this procedure.

One gets similar improvements for smaller values of . For instance for (corresponding to ), we have , , , and , , , . Thus it should be a lot faster to verify than , as the former left-hand side oscillates less rapidly and is also more likely to stay further away from the origin, so one would need fewer points to evaluate the function.

As suggested by KM one might also multiply through by the Euler product at 3 and 5 and perhaps get some further modest gains. (But at this point the complexity of evaluating these more complicated sums may overwhelm the gain coming from having fewer evaluation points.) Another thing one can try is to modify the Euler factors slightly, e.g. considering multiplying by for some parameter that is not necessarily equal to 1. Right now I am using as this kills off completely the term in the sum, but this might not necessarily be the best choice.

25 February, 2018 at 6:12 am

KMI was able to match the above numbers and generate estimates for all N from 1 to 1784 (x upto 4*10^7) upto the first 3 Euler factors.

Interesting N values

——————–threshold

estimate————0—0.05–0.1

|b5(x)|-|a5(x)|—282—308—338

|b3(x)|-|a3(x)|—322—352—387

|b2(x)|-|a2(x)|—478—527—582

|b1(x)|-|a1(x)|–1391–1559–1761

N=338 corresponds to x ~ 1.5 million

upper bound of derivatives

———————–N range

estimate—————1-28—29-63–64-89–90-199–200-282–283-337

max|b’5(x)|+|a’5(x)|—4.05—3.86—3.32—3.04—-2.24—-1.89

max|b’3(x)|+|a’3(x)|—3.44—3.43—3.14—2.92—-2.23—-1.91

max|b’2(x)|+|a’2(x)|—3.10—3.17—3.09—2.93—-2.34—-2.04

max|b’1(x)|+|a’1(x)|—3.61—3.82—3.79—3.66—-3.02—-2.66

N=28 corresponds to x=10568. Assuming |A+B|/|B0| stays over 0.4 beyond N=28, this indicates a mesh size of 0.1 or slightly lower would work at the start.

Also, the derivative bound fluctuates in lower N ranges, and at higher ranges max|b’2(x)|+|a’2(x)| is not very different compared to

max|b’p(x)|+|a’p(x)| with p>2.

25 February, 2018 at 12:18 am

AnonymousSome of the formulas in comments have log^2(N^2 / n) and in later comments similar formulas have log(N^2 / n) instead. Is that real or a typo?

[Oops, a typo: it should be single power of log throughout, thanks – T.]25 February, 2018 at 4:45 am

VsevolodQuite a small typo: “or at least the toy counterpart” instead of “ot at least the toy counterpart”

[Corrected, thanks – T.]25 February, 2018 at 5:59 am

David Bernier (@doubledeckerpot)After correcting a sign error I made in defining , I get excellent agreement between the tables in the wiki and my PARI/gp version of them. Below, I recopy the corrected functions needed to define in Pari/GP:

B(Z)=(1/8)*exp((t/4)*conj(al1(I*real(Z)/2+(1+imag(Z))/2))^2)*conj(H01(I*real(Z)/2+(1+imag(Z))/2))*sum(Y=1,M(Z),1/exp((-I*real(Z)/2+(1+imag(Z))/2+conj(t*al1(I*real(Z)/2+(1+imag(Z))/2))/2-(t/4)*log(Y))*log(Y)))

al1(S)=1/(2*S)+1/(S-1)+(1/2)*log(S/(2*Pi))

H01(S)=(S*(S-1)/2)*exp((-S/2)*log(Pi))*sqrt(2*Pi)*exp((S/2-1/2)*log(S/2)-S/2)

M(Z)=floor(sqrt((real(Z)/2-Pi*t/8)/(2*Pi)))

25 February, 2018 at 1:42 pm

RudolphDavid,

Below the Pari/GP code I wrote to compute Ht-effective including all the error terms. Maybe you could use parts of it or compare outcomes with your own code. It already contains the fix of the small sign error in and that was spotted today (I checked the impact and it is indeed very small).

Overall very good matches with the Wiki data, although small differences (in the 3rd digit) emerge at higher x. On Github, we have compared the output with KM’s mpmath program and the only remaining (small) difference seems to reside in the method of computation of the vwf-integral. The vwf-integral limits in the code are currently set at 6. The value of t can be set at the top.

\\Ht_effective A + B + Err (=E1 + E2) + C (=E3)

\\init

default(realprecision, 20)

t=0.4

intlim=6

S(s)=real(s)

T(s)=imag(s)

S1(s)=1-S(s)+T(s)*I

Td(s)=T(s)+Pi*t/8

T3(s)=T(s)-3.33

T4(s)=12*(Td(s)-0.33)

M(s)=floor(sqrt(Td(s)/(2*Pi)))

\\calculate A and B

ALF(s)=1/(2*s)+1/(s-1)+1/2*log(s/(2*Pi))

H00(s)=(s/2)*(s-1)*Pi^(-s/2)

H01(s)= H00(s)*sqrt(2*Pi)*exp((s-1)/2*log(s/2)-s/2)

QA(s,n)=s+t/2*ALF(s)-t/4*log(n)

QB(s,n)=1-s+t/2*conj(ALF(S1(s)))-t/4*log(n)

A0(s)=exp(t/4*ALF(s)^2)*H01(s)

B0(s)=exp(t/4*conj(ALF(S1(s)))^2)*conj(H01(S1(s)))

A(s)=A0(s)*sum(n=1,M(s),1/(n^(QA(s,n))))

B(s)=B0(s)*sum(n=1,M(s),1/(n^(QB(s,n))))

\\eps error

SE(s,n)=s+t/2*ALF(s)-t/4*log(n)

ER(s)=1/(2*T3(s))*(1/4*t^2*(abs(ALF(s))^2)+1/3+t)

EPS(s)=zeta(real(SE(s,M(s))))*exp(ER(s))*ER(s)

Err(s)=abs(A0(s)*EPS(s))+abs(B0(s)*EPS(S1(s)))

\\C and vwf error

a0(s)=sqrt(Td(s)/(2*Pi))

v1(sig,s)=1+0.4*9^(sig)/a0(s)+0.346*2^(1.5*sig)/(a0(s)^2)

v21(sig,s)=0.9^(ceil(-sig))

v22(sig,s)=sum(k=1,floor(-1*sig)+4,(1.1/a0(s))^k*gamma(k/2))

v2(sig,s)=1+v21(sig,s)*v22(sig,s)

v(sig,s)=if(real(sig)>=0,v1(sig,s),v2(sig,s))

w1(sig,s)=1+(sig^2)/(Td(s)^2)

w2(sig,s)=1+((1-sig)^2)/(Td(s)^2)

w3(sig,s)=(sig-1)*log(w1(sig,s))/4+w4(sig,s)+1/T4(s)

w4(sig,s)=if(sig<0,(Td(s)/2*atan(sig/Td(s))-sig/2),0)

w(sig,s)=sqrt(w1(sig,s))*sqrt(w2(sig,s))*exp(w3(sig,s))

f1(sig,s)=exp((-1/t)*(sig-S(s))^2)

f(sig,s)=(1/(2*sqrt(Pi*t)))*(f1(sig,s)+f1(1-sig,s))

vwf(s)=intnum(u = -intlim, intlim, v(u,s)*w(u,s)*f(u,s))

C1(s)=sqrt(Pi)*exp(-(t*Pi^2)/64)*(Td(s))^(3/2)*exp(-Pi/4*T(s))

C(s)=C1(s)*vwf(s)

\\all components together

E(s)=1/8*(A(s)+B(s)+C(s)+Err(s))

H(z)=(E(I*real(z)/2+(1-imag(z))/2))

\\generate output: note that Ht(x+yi)=E(1/2+(x+y*i)/2*i)

print((H(10000000+0.4*I)))

print((E(1/2+(10000000+0.4*I)/2*I)))

print((1/8*B0(1/2+(10000000+0.4*I)/2*I)))

print((B(1/2+(10000000+0.4*I)/2*I)/B0(1/2+(10000000+0.4*I)/2*I)))

︡4.6138 E-1705458 – 1.4530 E-1705457*I

4.6138 E-1705458 – 1.4530 E-1705457*I

2.1644 E-1705458 – 9.6337 E-1705458*I

1.6400 + 0.019799*I

25 February, 2018 at 4:03 pm

RudolphOops. Compared the code once again with the Wiki-formulae and spotted a mistake. The C-factor should not be divided by 8, so the correct line should be:

E(s)=1/8*(A(s)+B(s)+Err(s))+C(s)

The 1/8 factor can of course also be applied directly to A(s),B(s) and Err(s), when they are defined.

Fortunately the impact of this error on the final result is small.

25 February, 2018 at 4:40 pm

Terence TaoActually, you discovered a typo in the wiki! The 1/8 should in fact be applied to the E_3 error, sorry about that. Fortunately this typo moves in the “good” direction :)

25 February, 2018 at 9:21 am

Terence TaoI made a minor sign error in the effective error estimates, but fortunately it is in a good direction: the quantities and , which were previously defined as and respectively, are instead and (I had the wrong sign for in the estimation of ). This slightly changes in the approximation, which is now rather than . I found this because the formula for in the comments above also had the plus sign instead of the minus one, which looked inconsistent or at least suspicious. I don’t think this changes the previous numerics substantially though, given how small is.

25 February, 2018 at 11:12 am

Terence TaoIt seems the calculations for the toy problem are clarified using the language of Dirichlet series. Indeed observe that

where , , and . The vanilla triangle inequality argument gives

where , thus one can keep so long as

these are the same bounds as before.

Now the Euler factor trick can be viewed as a special case of the standard analytic number theory trick of mollifying a Dirichlet series by multiplying it by a short Dirichlet polynomial to remove some of the main sources of oscillation. Indeed, one can multiply and by the same Dirichlet polynomial for an arbitrary collection of coefficients to obtain

If we normalise , the triangle inequality then gives

and we can now ensure that so long as

The vanilla triangle inequality corresponds to just using and . Using the Euler factor at 2 corresponds to taking , , and (this cancels the summand of the term). This might not be the optimal choice of to use in the case. Using the Euler factor at both 2 and 3 corresponds to taking , , , , , and all other vanishing (incidentally my calculations for this case differ slightly from KM’s, though I was able to confirm his calculations for and , I think the contribution of the term could be a bit tricky, as I had made some errors by hand with this term before). However, one is free to use other values of , and it could be that this could lead to further ranges of for which we can guarantee (thus far we tentatively seem to have reached all the way down to ).

25 February, 2018 at 11:42 am

Terence TaoHere is a lemma that may be useful.

LemmaLet be real numbers for with and . Let be a real number, and suppose thatThen one has

whenever .

RemarkThe condition (1) improves a little bit upon the conditionthat one gets from directly applying the triangle inequality; the gain is particularly good when have coherent signs (e.g. they are all positive). Intuitively, the point is that the triangle inequality is only sharp if the are all negative reals for , and the are all the same phase for , and this is inconsistent with all the having the same sign (with and positive).

ProofIt suffices to show that for any real phase , the quantityis non-zero. By the triangle inequality, we can do this if

Observe from the cosine rule that

is a fractional linear function of with no poles in the range of , and is hence monotone on this interval Thus attains its maximum either when or , thus

and the claim follows.

Using this criterion in place of the triangle inequality, and not using any Euler factor mollifiers, I can improve the threshold that KM obtained to . Presumably similar gains can be obtained when one combines this lemma with the Euler factors (or with other Dirichlet mollifiers, as I mentioned in the previous comment), but I haven't tried this.

26 February, 2018 at 9:26 am

KMUsing the sharper inequality, I was able to match N=1080 with no Euler factor, but the results with the factor mollifiers seem aggressive.

Mollifier—N

Euler2—–296

Euler3—–136

Euler5——80

N= 80 corresponds to 80425!! This may need to be double checked.

where b_p_n = exp(0.1*logn*logn)*|conditional factor_p_n| using the coefficients derived earlier.

Also, I was able to run |b_p(x)| – |a_p(x)| delta evaluations with fixed mesh size 0.1 for all x between 10k and 200k (1.9 mil evaluation points) and p=1,2,3. From earlier data, the upper bound of |b’p(x)| + |a’p(x)| was known to be below 4, so I was looking for events where the delta was below 0.4.

For |b_1(x)| – |a_1(x)|, the last such event was at x=38280 (N=55) for a total of 782 events. Minimum was 0.186 reached at 17291.2

For |b_2(x)| – |a_2(x)|, this occured at x=22024 (N=41) for a total of 152 events. Minimum was 0.185 reached at 10530 (the earlier point was a close second)

For |b_3(x)| – |a_3(x)|, this occured at x=21538.5 (N=41) for a total of 72 events. Minimum was 0.201 reached at 17291.2

Using a mesh size of 0.05, the region x=10k to 22k was again verified, looking for delta values below 0.16 (since max|b’2(x)|+|a’2(x)| in the N range 29-63 was 3.17), but no such values were found, thus clearing all the points.

It would have been better to use a adaptive mesh as suggested earlier, rather than use such a iterative procedure.

Also, you mentioned that arbitrary lambda coefficients are allowed in the mollifiers, but just wanted to share the way I had proceeded with the d=6 derivation earlier

leading to the final conditional factors

26 February, 2018 at 4:38 pm

Terence TaoThanks for this! The bounds are looking remarkably good, I will try to double check them with my somewhat primitive Maple skills. It also seems that your calculation of the d=6 term was correct and mine was wrong.

If this all checks out it seems that we actually have a numerical verification of the non-vanishing of for all . Next we would have to adapt these methods to . A new technical difficulty here is that there is an expression in the exponent which depends on and not just on . However the dependence on x is rather mild and we may be able to somehow approximate by something that only depends on .

As requested I will try to upload my Maple code to the git repository, though I am not really proficient in these things and I would hardly recommend using my code for much other than confirmation.

26 February, 2018 at 5:25 pm

KMI was also able to write a general procedure for the triangle inequality estimates, which can use any number of Euler factors (although it’s quite slow at the moment). Using 4 factors, the 0 threshold was crossed slightly below N=265. Will try to adapt it for the sharper inequality as well.

26 February, 2018 at 7:03 pm

Terence TaoKM, so far I have verified the triangle inequality thresholds of using respectively, and for using and the Lemma. However I am getting different (and slightly worse) results than your for the use of the Lemma with ; will report on the thresholds I get soon (and then I will also work on confirming ). Looking at your code, I think the problem is that one shouldn’t be putting absolute values around the cond[n][] terms in lines 221, 222 of ab_analysis.py; the signs of bn2, an2, etc. are actually rather important in the Lemma. By the way I am also putting the lemma and the numerical results on the wiki page.

EDIT: For I get (replacing ). For I get (replacing ).

EDIT2: threshold for confirmed. For I get (i.e. worse than )!

EDIT3: I can improve the threshold for slightly to by dropping the term from the mollifier, i.e. taking and all other terms zero.

27 February, 2018 at 9:19 am

KMThanks, I removed the absolute part around the cond terms. There was another typo where i was using bn and an to compute bn2,an2,bn3,…, thus multiplying two conditional terms, instead of treating them independently.

I was able to match N=341 for E2 + Lemma and N=220 for E3+ Lemma. But I am getting N=192 for E5 + Lemma (at N=241, the estimate is coming out to be 0.888)

Using the general procedure with the sharper inequality, I get N=180 for E7+Lemma, and 176 for E11 + Lemma

I have also started a x point evaluation run for x between 200k and 600k (N=219) with an adaptive mesh.

27 February, 2018 at 1:42 pm

Terence TaoAh, I made a stupid typo in my own code. I can now confirm your value of for .

27 February, 2018 at 11:59 am

KMI wasn’t able to replicate N=213 with the custom mollifier , and instead got N=235. For now, I have added a function abtoy_custom_mollifier in ab_analysis.py, and will experiment again later with different mollifiers.

27 February, 2018 at 4:18 pm

Terence TaoGah, you’re right; the same typo that caused an error in my previous calculation was also present here. I’ve confirmed your value of 235. So I guess this is not a good mollifier :)

1 March, 2018 at 12:25 pm

KMCustom mollifiers do work. By treating the lambda coefficients as parameters to be optimized, and minimizing the Lemma sum using a standard minimization algorithm (the sum for D=30 wasn’t fully minimized), we get

1 March, 2018 at 5:14 pm

Terence TaoGreat! I’ve added this to the wiki (now moved to http://michaelnielsen.org/polymath1/index.php?title=Controlling_A%2BB/B_0 because the previous page http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem was becoming slow to load). It seems that trying to optimise the mollifier shrinks the range of x that we need to check by about 10-20% which is not that dramatic, but perhaps these sorts of optimisations add up (or more precisely, multiply up) after a while…

26 February, 2018 at 1:37 pm

AnonymousI can’t find the code that participants are using for this project, the github linked from the project wiki hasn’t had any commits in almost two weeks.

26 February, 2018 at 4:55 pm

KMActually, all the new code is in the adjusted AB branch which has been in merge review since couple of weeks. Have merged that and Prof. Tao’s recent branch (with Maple code and relevant papers) into master, which is much easier to find.

In the python folder, please check mputility.py and the research folder.

27 February, 2018 at 10:15 am

RudolphI acknowledge that the main task now is to establish the lowest possible x-bound beyond which . The encouraging results of the toy-model indicate that this x-bound is going to be brought well in reach of computing that (and ) doesn’t vanish below that. In the context of computation, I would like to share the outcomes of an experiment I did.

In a nutshell: an x-ray plot shows all the points where (green lines) and (red lines), so the H_t-function only vanishes when the two lines cross. For a certain fixed , a real line (that wiggles quite a bit) is always accompanied by two imaginary lines (which are much better behaved). Hence the idea to measure the distance a green line keeps from its embracing red lines and then to calculate the distribution of these distances over a wide range of .

The approach is visualised here: https://ibb.co/jTihiH

The distributions for various over ranging from 1000 to 50000 (yielding 62870 ‘s), for both and is shown here: https://ibb.co/m1cExc

Few observations:

1) The line doesn’t oscillate, hence to embrace I used .

2) I appreciate that the Ht-ABC-formula has been deprecated now, however since we don’t have an effectively bounded C-error term for lower yet, I still used it to produce the plots (also since the match with at lower was pretty good).

3) The data looks encouraging for the problem at hand. Distributions clearly tend to convergence towards more ‘normal’ shapes with increasingly emptier ‘tails’, when and move away from zero.

4) I wonder whether it is correct to say that when the distribution for has empty tails say below 40% and above 60%, that given certain error terms of say max 5%, that line then must be zero-free up to ?

Couldn’t resist a philosophical note :)

The paraphrased Newman-quote: ‘RH if true, then it is barely so’ is also illustrated by the plots. When and move towards zero, the distribution gets increasingly wider. Assuming the RH (), the non-trivial zeros apparently need to get ‘crammed’ into all the available slots at to be able to encode the required information about the error term in the distribution of primes. The zeros seem to dangerously balance on the thin edge of a real cliff and even the tiniest negative would already push some of them over into the sea of complex numbers…

27 February, 2018 at 10:51 am

AnonymousHah! That Newnan quote is ‘barely’ rubbish.. And RH is true! 😄

27 February, 2018 at 4:29 pm

Terence TaoNice pictures! One small thing: I think the notational conventions we’ve been using are to use for the argument of , and for the argument of (thus for instance ). It seems your conventions may differ from this by a factor of two, although for the purposes of qualitative illustration this probably doesn’t matter.

28 February, 2018 at 4:30 am

RudolphYou are absolutely right and I should have been much clearer on why I used as the argument! I actually did start from the convention that with , however then consciously multiplied by to obtain that allows for better (visual) comparison to known values (zeros) of (for instance the sample x-ray in the first picture is from the area where the first Lehmer pair did induce some still visible ‘wiggles’ in the green lines).

28 February, 2018 at 9:19 am

Terence TaoIn that case your y=0.4 may in fact correspond to what the rest of us would call y=0.8 (but I am not 100% sure on this, perhaps one can crosscheck against some of the numerical data in http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem#Choices_of_approximation , which is for y=0.4 in our notation).

27 February, 2018 at 9:45 pm

Terence Taop.s. I have now updated the wiki page at http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem#Choices_of_approximation with the refined approximation to . In practice it seems that stays quite close to (and stays close to ).

28 February, 2018 at 8:16 am

David Bernier (@doubledeckerpot)This is my first try at translating into PARI/gp.

It gives H_0(28.2073) ~= 0 , which seems quite good.

Heff2(Z)=A(Z)+B(Z)-C(Z)

C(Z)=(1/8)*exp(t*(Pi^2)/64)*(sp(Z)*(sp(Z)-1)/2)*((-1)^M(Z))*(Pi^(-sp(Z)/2)*gamma(sp(Z)/2)*(a(Z)^(-sig(Z)))*C0(Z)*U(Z)+Pi^(-(1-sp(Z))/2)*gamma((1-sp(Z))/2)*(a(Z)^(-(1-sig(Z))))*conj(C0(Z))*conj(U(Z)))

sp(Z)=(1-imag(Z))/2+I*real(Z)/2+I*Pi*t/8

a(Z)=sqrt((real(Z)/2+Pi*t/8)/(2*Pi))

sig(Z)=real(sp(Z))

C0(Z)=(exp(Pi*I*((p(Z)^2)/2+3/8))-I*sqrt(2)*cos(Pi*I/2))/(2*cos(Pi*p(Z)))

U(Z)=exp(-I*((Tp(Z)/2)*log(Tp(Z)/(2*Pi))-Tp(Z)/2-Pi/8))

Tp(Z)=real(Z)/2+Pi*t/8

p(Z)=1-2*(a(Z)-M(Z))

M(Z)=floor(sqrt((real(Z)/2+Pi*t/8)/(2*Pi)))

A(Z)=(1/8)*exp((t/4)*(al1(I*real(Z)/2+(1-imag(Z))/2)^2))*H01(I*real(Z)/2+(1-imag(Z))/2)*sum(Y=1,M(Z),1/exp((I*real(Z)/2+(1-imag(Z))/2+t*al1(I*real(Z)/2+(1-imag(Z))/2)/2-(t/4)*log(Y))*log(Y)))

B(Z)=(1/8)*exp((t/4)*conj(al1(I*real(Z)/2+(1+imag(Z))/2))^2)*conj(H01(I*real(Z)/2+(1+imag(Z))/2))*sum(Y=1,M(Z),1/exp((-I*real(Z)/2+(1+imag(Z))/2+conj(t*al1(I*real(Z)/2+(1+imag(Z))/2))/2-(t/4)*log(Y))*log(Y)))

H01(S)=(S*(S-1)/2)*exp((-S/2)*log(Pi))*sqrt(2*Pi)*exp((S/2-1/2)*log(S/2)-S/2)

al1(S)=1/(2*S)+1/(S-1)+(1/2)*log(S/(2*Pi))

B0(Z)=(1/8)*exp((t/4)*conj(al1(I*real(Z)/2+(1+imag(Z))/2))^2)*conj(H01(I*real(Z)/2+(1+imag(Z))/2))

====

? real(Heff2(28.207303425056217036624775835617549798))

= 1.6860423122756198997 E-41

? t

= 0.E-38

28 February, 2018 at 9:32 am

Terence TaoThanks for the confirmation! That is remarkably good accuracy for such a small value of . I wonder if it would be possible to have some comparative tables or plots of , and for such values of (perhaps normalised by dividing by something like to eliminate the exponential decay). It may help give a sense of when the approximation is no longer viable, in which case one would need to switch to (and get better explicit error terms).

28 February, 2018 at 10:34 am

David Bernier (@doubledeckerpot)I think I can produce that normalized data (after dividing by . Indeed, 28.207 is pretty close to twice 14.13 (first non-trivial zeta zero).

The computer is working on this:

I’m computing the absolute value of for 20 real numbers from 160 to 3200. Here, includes the term, and is computed using the integral formula defining .

T.B.C. …

28 February, 2018 at 11:40 am

David Bernier (@doubledeckerpot)[ continued…]

There seems to be a local maximum once again near .

The PARI/gp code to do the comparison of with , with the output, is copied below:

? \p 550

realprecision = 558 significant digits (550 digits displayed)

? w20=vector(20)

= [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

? t=0.4

[…]

? intnumgaussinit(800);

[…]

? for(K=1, 20, x50= K*160 ;s=0.0;for(J=0,30,s=s+intnumgauss(X=J/13,(J+1)/13, exp(t*X*X)*Phi(X)*cos((x50)*X),)); s2=Heff2(x50); b0=B0(x50);s4 = abs((s2-s)/b0);w20[K] = s4;)

? \p 10

realprecision = 19 significant digits (10 digits displayed)

? for(K=1,20, print(K*160,” “, w20[K]))

160 0.009155667752

320 0.0005529962481

480 0.0004966282128

640 0.0004482768972

800 0.002686105466 // local maximum

960 0.001270168744

1120 0.0009957229500

1280 0.0007024411378

1440 0.0007000473085

1600 0.0004882487218

1760 0.0002518910919

1920 0.0008378989413

2080 0.0004924765754

2240 0.0001171320991

2400 0.0002443802551

2560 0.0004569058755

2720 0.0006355966221

2880 0.0008864917365

3040 4.326840265 E-5

3200 0.0003598521453

28 February, 2018 at 1:01 pm

Terence TaoThanks for this data! I put it on the wiki at http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem#Controlling_.7CH_t-A-B.7C.2F.7CB_0.7C next to your previous data on (see third table) and the improvement in accuracy is substantial. Could you also give data for and for the same range of ? This would give some guidance as to the range of for which we would have to utilise the correction.

28 February, 2018 at 12:04 pm

David Bernier (@doubledeckerpot)Below, for the sake of getting results faster, I take as the “standard” to which is compared, after division by :

? QABeff(Z) = abs(A(Z) + B(Z) – Heff2(Z))/abs(B0(Z))

? for(K=3,7, print(10^K,” “, QABeff(10^K)))

1000 0.15607

10000 0.033581

100000 0.0077278

1000000 0.0017772

10000000 0.00026013

28 February, 2018 at 1:15 pm

Terence TaoIs your the same as ? If so, then I guess your would be . I get very slightly different data for this ratio (here I am assuming ):

1000 0.1659471018

10000 0.03571919360

100000 0.008219920842

1000000 0.001890567784

10000000 0.0002777949355

The differences are small, but I’d like to pin it down – probably there is a typo in my own code since it seems your implementation approximates to very high accuracy. For , for instance, I am getting these values:

Does this match your numbers?

28 February, 2018 at 1:11 pm

David Bernier (@doubledeckerpot)This is sample code to write to a file the normalized values of , :

? for(K=20, 1000, x50=K; w = (A(x50)+B(x50))/B0(x50); write(outputHeffAB, x50,” “, w))

? for(K=20, 1000, x50=K; w = Heff2(x50)/B0(x50); write(outputHeffABC, x50,” “, w))

But I don’t know how to do plots in PARI/gp .

28 February, 2018 at 2:03 pm

RudolphFor z^3, t=0.4 I am currently getting (hoping my code is correct…):

A_eff -5.8191933398261330947 E-168 – 3.0393189395893835125 E-167*I

B_eff -5.8191933398261330947 E-168 + 3.0393189395893835125 E-167*I

C_eff -4.9757097161525819004 E-168 + 0.E-205*I

B0_eff 1.8394229213245936177 E-167 + 2.6038636181013073063 E-167*I

Just to show the good match I get between the -function (1st) with (A+B-C)_eff. C-term listed independently (3rd) at t=0, y=0:

x=25

0.00066948088996085741409 – 7.174648137343063403 E-42*I

0.00065734215678865204259 + 0.E-41*I

0.0002148587374553108988

x=50

1.7280715206373737196 E-9 – 1.9158377441940858392 E-47*I

1.6625508526575364227 E-9 + 0.E-45*I

7.4751288517910783610 E-8 + 0.E-45*I

x=100

3.9527439074473614238 E-16 – 1.1093017595597491695 E-53*I

3.9779357479763186216 E-16 + 0.E-53*I

-4.0160884429998658723 E-16 + 0.E-53*I

x=500

1.0763588275034730133 E-82 + 5.653984195680004678 E-119*I

1.0770837316884739789 E-82 + 0.E-120*I

-2.1026699008978412660 E-83 + 0.E-120*I

x=1000

-3.0912467355888789916 E-167 – 3.251797352795581408 E-203*I

-3.0904791459693381129 E-167 + 0.E-205*I

-5.2704332443772292555 E-168 + 0.E-205*I

x=10000

1.1326355002579265086 E-1700 + 2.3068258704312139077 E-1736*I

1.1324594118594644316 E-1700 + 0.E-1738*I

-1.4441315742576007239 E-1701 + 0.E-1738*I

28 February, 2018 at 2:47 pm

AnonymousI can confirm the full precision of Rudolph’s values for , , and using my own implementation based on the wiki for , but I haven’t yet implemented the correction.

28 February, 2018 at 2:57 pm

David Bernier (@doubledeckerpot)Yes, it should all be the effective type, unless I’m mistaken.

I seem to get the same thing as you for , slightly different w.r.t. and , and really different for :

? x50=1000; w = A(x50); print(w)

-5.819193340 E-168 – 3.039318940 E-167*I

? x50=1000; w = B(x50); print(w)

-5.819193340 E-168 + 3.039318940 E-167*I

? x50=1000; w = C(x50); print(w)

-4.975709716 E-168 + 0.E-186*I

? x50=1000; w = B0(x50); print(w)

1.839422921 E-167 + 2.603863618 E-167*I

28 February, 2018 at 4:13 pm

Terence TaoAh, thanks for this, I tracked down the bugs in my own code. (For the record: I had used instead of , and I had also omitted the factor of .) My data now matches yours to three significant figures; for instance I have now. The discrepancy is a lot smaller but I’d still like to pin down what’s going on; as far as I can tell it is not simply a matter of not having enough digits of precision. Staying with , I also calculate

Do these correspond to the numbers you are getting?

28 February, 2018 at 4:38 pm

RudolphI got:

Co(p) 0.376348307023843 + 1.58717855690832*I

U -0.577931232612849 – 0.816085467564882*I

Gamma(s’/2) 1.33354873965418 E-171 – 8.49347508127889 E-172*I

So, the difference seems to be only in the imaginary part of C0(p). The error could easily be in my code, but here is a thought: for C0 my code is:

C0(s)=(exp(Pi*I*((P(s)^2)/2+3/8))-I*sqrt(2)*cos(Pi*I/2))/(2*cos(Pi*P(s)))

I can simply put C0(s) since the only variable is P(s), so I will always get p as the outcome. When I would put in C0(P(s)), it would give a very different outcome. I think that somewhere in this space the difference originates from.

28 February, 2018 at 5:24 pm

AnonymousAgain I get the same numbers as Rudolph for those three parts of when I use the formulas on the wiki.

C0 : 0.37634830702384258887 + 1.5871785569083238623*I

U : -0.57793123261284940132 – 0.81608546756488229758*I

Gamma(s’ / 2) : 1.3335487396541778349e-171 – 8.4934750812788891334e-172*I

28 February, 2018 at 5:48 pm

AnonymousThere’s a typo in the wiki where should be . With this correction I get imaginary part 0.22927801920219723181 matching Terry’s number.

28 February, 2018 at 5:52 pm

Anonymousimaginary part -0.22927801920219723181 I mean, with the negative sign. The typo is in the last part of the numerator of the definition of in http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem#Choices_of_approximation.

1 March, 2018 at 9:27 am

Terence TaoThanks for this! I’m glad now that we tracked down the numerical discrepancy, we might not have discovered the typo for a long time otherwise. I’ve corrected the wiki.

28 February, 2018 at 6:13 pm

David Bernier (@doubledeckerpot)Right now, the computer is working on the data for the table: z = 160 to 3200, (integral) compared to …

28 February, 2018 at 6:18 pm

RudolphGood catch, that must be it.

One more question: when we ‘call’ C0 from the formula for C, should we use s or s’ ? It is only a small difference, but just be sure.

1 March, 2018 at 9:29 am

Terence TaoWell, the way it is done in the wiki, is a function of , which is in turn a function of and , which are functions of , which is the imaginary part of , which is a shifted form of . So one could make a function of , or of , or of , or of , depending on how one codes it.

28 February, 2018 at 6:59 pm

AnonymousSorry Rudolph I can’t answer your questions about “when we ‘call’ C0 from the formula for C, should we use s or s’” or “I can simply put C0(s) since the only variable is P(s), so I will always get p as the outcome”. Maybe they’re technical questions about how to use Pari/GP but I’m not using that system and I haven’t used it.

28 February, 2018 at 8:32 pm

AnonymousFor I see -4.9767102201547040018e-168 which is off by exactly a factor of 10 from what Terry wrote, but I assume he just typo’d 167 instead of 168 when writing his comment.

[Yes, that was a typo on my part – T.]28 February, 2018 at 11:39 am

RudolphAlso got the code for new C working and the match at t=0 seems excellent even at small x (can confirm David’s zero at 28.207). Could there be a small typo on Wiki where C0(p) should actually be C0(s) (also for its conjugated version)?

28 February, 2018 at 12:53 pm

Terence TaoIt should indeed be (though, as ultimately depends on , one could also view as a function of ). Here I am following the notation of the Arias de Reyna paper https://pdfs.semanticscholar.org/7964/fbdc0caeec0a41304deb8d2d8b2e2be639ee.pdf (see e.g. equation (5.2)).

28 February, 2018 at 2:05 pm

RudolphYou’re right! It should be indeed, apologies for the false alarm.

1 March, 2018 at 7:34 am

RudolphA final question just to be sure that I have translated the wiki-formulae correctly into computer code.

On wiki, the definition of uses as the main variable in the arguments of all its components. Since ultimately is a function of , should the in the component be dependent on or also on ? For the same question could be raised.

For , the choice would give this difference in :

using

using

1 March, 2018 at 9:47 am

Terence TaoFrom my reading of David’s code, it seems that is a function of (which is called Z in the PARI code) rather than (as the shift by is coded into these functions), so one would use as the input for David’s function rather than .

28 February, 2018 at 4:41 pm

AnonymousI don’t see the definition of in , is it ?

[Yes, I have updated the wiki to reflect this – T.]27 February, 2018 at 11:48 am

AnonymousThis is probably a dumb question but are there explicit tail bounds for the E3 improper integral error term?

27 February, 2018 at 4:12 pm

Terence TaoNot yet; that’s something I plan to look at soon, as it looks like is the dominant error and also the one which is hardest to estimate at present.

28 February, 2018 at 3:22 am

anonymousIt’s not clear to me what the optimal way of bounding will be, but one simple-minded way is just to truncate the integral defining it at some large values of , relying on the decay of and the not-too-fast increase of to show that outside this truncation the integral is small, while inside the truncation is close to 1, and otherwise evaluate everything algebraically as far as possible.

This is complicated a little bit by discontinuities in the definition of , but I think these should be able to be dealt with in one way or another.

I’ve only gotten as far as to estimate inside some hypothetical cutoffs, and even then I’ve not made an effort to optimize these cutoffs and just done a sort of back-of-the-envelope computation with _a lot_ of lost information in the constants. Nonetheless, it seems that something like the following will be true:

For say, for ,

,

while for , the same bound holds true.

Haven’t yet plugged these into the integrals or dealt with the range outside this truncation…

28 February, 2018 at 4:47 pm

Terence TaoThis is a promising approach! I will try it and see what I get.

27 February, 2018 at 12:15 pm

AnonymousOn the wiki page for this test problem, should the second be ?

[Corrected, thanks – T.]27 February, 2018 at 1:29 pm

AnonymousI think there’s a sign typo on this thread’s wiki, where in part of the definition of should be .

27 February, 2018 at 2:01 pm

AnonymousIf the sign is correct, then there is a corresponding typo in the effective bounds wiki page; the signs are inconsistent between these two pages.

27 February, 2018 at 4:11 pm

Terence TaoIt was the effective wiki page that had the sign error, now corrected; thanks for pointing it out.

27 February, 2018 at 4:49 pm

Terence TaoI have entered some calculations on the wiki on how to transition from the toy model to the effective approximation.

Currently, to show that is non-vanishing, we have to verify that

where has real part (and imaginary part , though this imaginary part has not played much role so far), , , and we took . We now have a number of ways to establish this lower bound for various values of .

For the problem of showing that is non-vanishing, it similarly suffices to verify that

where has a more complicated form than , but the real part is greater than or equal to (assuming , which we have right now), is as before, is very slightly different as (thus where ), and turns out to take the form

where is the small quantity

(roughly of size ) and is a small error

(roughly of size ). So, up to the and factors, is basically the same as , and the previous analysis should go through (the fact that is slightly larger than actually works in one's favor, one can simply just use the criteria we have with just ). The one annoying thing is that the error term is complex valued, and the Lemma that has been giving the best values of requires real coefficients. So one basically has to extract out the errors separately using the triangle inequality, leading to a messier criterion for showing non-vanishing (or for more generally lower bounding the LHS of (1)). In principle one can also insert the Euler product mollifiers as before; the criterion then gets somewhat messy but should still be usable.

28 February, 2018 at 11:31 am

KMFor the effective approximation with the Lemma inequality, the same bounds as the current toy bounds seem to hold (I checked with upto 2 Euler factors) – 1080, 341, 220. Away from the critical N value we get different estimates. For e.g. at N=100, |b2| – |a2| toy estimate is 1.612 and effective estimate is 1.515, but they both go below 1 at N=341.

Also, I stopped the adaptive mesh x point toy evaluation at 500k (N=199) (which was started at x=200k). Mesh size was determined as (|b2(x)|-|a2(x)|)/4. Minimum value for |b2(x)|-|a2(x)| was 0.604. Hence with the earlier exercise upto 200k, the entire range 10k to 500k has been now considered. I will now evaluate the effective approximation for the same range.

28 February, 2018 at 11:50 am

KMAlso some minor typos in that section of the wiki. The triangle inequality has the n^sigma factor missing, and in the Lemma inequality, 1-a1 and 1+a1 should be flipped.

28 February, 2018 at 1:06 pm

Terence TaoGood catches! I have corrected the wiki accordingly.

27 February, 2018 at 6:41 pm

AnonymousIn the “Final bound” section of the effective bounds wiki page and in the effective bounds section of the test problem page, some of the error terms involve a . Should these be or or does the mean or something else?

[ is ; I have added this to the description. -T.]28 February, 2018 at 3:50 pm

David Bernier (@doubledeckerpot)For the range 160 to 3200, I can provide data for tables, after a break :)

28 February, 2018 at 6:52 pm

David Bernier (@doubledeckerpot)This is what I get for in absolute value:

? for(K=1, 20, x50= K*160 ;s=0.0;for(J=0,30,s=s+intnumgauss(X=J/13,(J+1)/13, exp(t*X*X)*Phi(X)*cos((x50)*X),)); s2=A(x50)+B(x50); b0=B0(x50);s4 = abs((s2-s)/b0);w20[K] = s4;)

? \p 19

realprecision = 19 significant digits

? for(K=1,20, print(K*160,” “, w20[K]))

160 0.1675083979955609185

320 0.2776948344513698276

480 0.1675667240356922231

640 0.1635077306008453928

800 0.2045038601879677257

960 0.1031837988358064657

1120 0.07541968034203085865

1280 0.1339118061014743863

1440 0.07958929988050262854

1600 0.07700542235140914608

1760 0.09568042045936396570

1920 0.06385275621986742745

2080 0.09421231232885752514

2240 0.05888587520703223358

2400 0.07899341548208345822

2560 0.06283843631123482445

2720 0.05966972584730198272

2880 0.07980560515423855917

3040 0.04636072344121703969

3200 0.09664223832561922043

1 March, 2018 at 9:40 am

Terence TaoJust to clarify: is this the same calculation as in your preceding comment https://terrytao.wordpress.com/2018/02/24/polymath15-fourth-thread-closing-in-on-the-test-problem/#comment-493282 , but with the corrected version of ? The accuracy seems to be somewhat worse with this new set of data.

1 March, 2018 at 1:57 pm

David Bernier (@doubledeckerpot)No, it’s a different calculation: it’s the normalized error in , as an approximation to (using the defining integral).

As far as I can tell, the corrected and do not affect values of …

1 March, 2018 at 5:21 pm

Terence TaoThanks for clarifying! I’ve added this to the table, which is now moved to http://michaelnielsen.org/polymath1/index.php?title=Controlling_H_t-A-B/B_0 because the page http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem was becoming slow to load. It is now quite clear that the C corrections do give a noticeable improvement in the accuracy of the approximation.

1 March, 2018 at 7:19 pm

David Bernier (@doubledeckerpot)One column is just a bit off, I think.

With the corrected , the normalized errors of compared to the integral formula are likely a bit smaller.

For example, with the corrected , for z=1600, I now get a normalized error of 0.000439823 (versus 0.000488248 on the wiki).

Except for z = 800, the normalized errors on the wiki used the old : the one with a typo. I’m recalculating.

? x50= 1600 ;s=0.0;for(J=0,30,s=s+intnumgauss(X=J/13,(J+1)/13, exp(t*X*X)*Phi(X)*cos((x50)*X),)); s2=Heff2(x50); b0=B0(x50);s4 = abs((s2-s)/b0); s4

= 0.0004398235678

1 March, 2018 at 9:26 pm

David Bernier (@doubledeckerpot)Using the corrected , the normalized error in looks marginally better, on average, than when using the with a typo :

? for(K=1, 20, x50= K*160 ;s=0.0;for(J=0,30,s=s+intnumgauss(X=J/13,(J+1)/13, exp(t*X*X)*Phi(X)*cos((x50)*X),)); s2=Heff2(x50); b0=B0(x50);s4 = abs((s2-s)/b0);w20[K] = s4;) // corrected C^eff

[…]

? for(K=1,20, print(K*160,” “, w20[K]))

160 0.00887362155217

320 0.000708716878236

480 0.000327585584191

640 0.000523969818792

800 0.00264434457030

960 0.000819848578351

1120 0.000978838228690

1280 0.000679785836479

1440 0.000655447626435

1600 0.000439823567873

1760 0.000231103881282

1920 0.000849398936325

2080 0.000505410233739

2240 0.000107206342271

2400 0.000229146425813

2560 0.000492123116208

2720 0.000656180976718

2880 0.000878298302262

3040 4.70113907733 E-5

3200 0.000354582706466

[New data added, thanks – T.]28 February, 2018 at 7:11 pm

David Bernier (@doubledeckerpot)My numbers are almost the same as Terry’s: the values differ in their imaginary parts only, it seems… :

? C0(1000)

= 0.3763483070 + 1.5871785569*I // not the same

? U(1000)

= -0.5779312326 – 0.8160854676*I // the same

? gamma(sp(1000)/2)

= 1.3335487397 E-171 – 8.4934750813 E-172*I // the same

28 February, 2018 at 7:14 pm

AnonymousDavid there’s a typo in the wiki (https://terrytao.wordpress.com/2018/02/24/polymath15-fourth-thread-closing-in-on-the-test-problem/#comment-493308) so

C0(Z)=(exp(Pi*I*((p(Z)^2)/2+3/8))-I*sqrt(2)*cos(Pi*I/2))/(2*cos(Pi*p(Z)))

should be changed to

C0(Z)=(exp(Pi*I*((p(Z)^2)/2+3/8))-I*sqrt(2)*cos(Pi*p(Z)/2))/(2*cos(Pi*p(Z)))

28 February, 2018 at 9:20 pm

David Bernier (@doubledeckerpot)I tested for comparison with (integral formula).

With C0 “new”, the error of is slightly smaller than

with C0 per the Wiki:

? C0new(Z) = (exp(Pi*I*((p(Z)^2)/2+3/8))-I*sqrt(2)*cos(Pi*p(Z)/2))/(2*cos(Pi*p(Z)))

? C0new(1000)

= 0.3763483070238425883 – 0.2292780192021972320*I

? C0(Z)=C0new(Z)

? x50= 800 ;s=0.0;for(J=0,30,s=s+intnumgauss(X=J/13,(J+1)/13, exp(t*X*X)*Phi(X)*cos((x50)*X),)); s2=Heff2(x50); b0=B0(x50);s4 = abs((s2-s)/b0); s4

= 0.002644344570 (versus 0.002686105466 in Wiki table).

1 March, 2018 at 11:04 am

anonymousWhen your main research reference is the first part of a seven year old two-part work that cites its second part as “to appear” https://i.imgur.com/IrSHTib.jpg

1 March, 2018 at 1:19 pm

David Bernier (@doubledeckerpot)After the wiki revision of now at: http://michaelnielsen.org/polymath1/index.php?title=Polymath15_test_problem#Controlling_.7CH_t-A-B.7C.2F.7CB_0.7C everything matches:

? C0(1000)

= 0.3763483070238425883 – 0.2292780192021972320*I

? U(1000)

= -0.5779312326128494048 – 0.8160854675648822951*I

? gamma(sp(1000)/2)

= 1.333548739654177835 E-171 – 8.493475081278889133 E-172*I

========================

user-defined functions :

A =

(Z)->(1/8)*exp((t/4)*(al1(I*real(Z)/2+(1-imag(Z))/2)^2))*H01(I*real(Z)/2+(1-imag(Z))/2)*sum(Y=1,M(Z),1/exp((I*real(Z)/2+(1-imag(Z))/2+t*al1(I*real(Z)/2+(1-imag(Z))/2)/2-(t/4)*log(Y))*log(Y)))

B =

(Z)->(1/8)*exp((t/4)*conj(al1(I*real(Z)/2+(1+imag(Z))/2))^2)*conj(H01(I*real(Z)/2+(1+imag(Z))/2))*sum(Y=1,M(Z),1/exp((-I*real(Z)/2+(1+imag(Z))/2+conj(t*al1(I*real(Z)/2+(1+imag(Z))/2))/2-(t/4)*log(Y))*log(Y)))

B0 =

(Z)->(1/8)*exp((t/4)*conj(al1(I*real(Z)/2+(1+imag(Z))/2))^2)*conj(H01(I*real(Z)/2+(1+imag(Z))/2))

C =

(Z)->(1/8)*exp(t*(Pi^2)/64)*(sp(Z)*(sp(Z)-1)/2)*((-1)^M(Z))*(Pi^(-sp(Z)/2)*gamma(sp(Z)/2)*(a(Z)^(-sig(Z)))*C0(Z)*U(Z)+Pi^(-(1-sp(Z))/2)*gamma((1-sp(Z))/2)*(a(Z)^(-(1-sig(Z))))*conj(C0(Z))*conj(U(Z)))

C0 =

(Z)->(exp(Pi*I*((p(Z)^2)/2+3/8))-I*sqrt(2)*cos(Pi*p(Z)/2))/(2*cos(Pi*p(Z)))

H01 =

(S)->(S*(S-1)/2)*exp((-S/2)*log(Pi))*sqrt(2*Pi)*exp((S/2-1/2)*log(S/2)-S/2)

Heff2 =

(Z)->A(Z)+B(Z)-C(Z)

M =

(Z)->floor(sqrt((real(Z)/2+Pi*t/8)/(2*Pi)))

Tp =

(Z)->real(Z)/2+Pi*t/8

U =

(Z)->exp(-I*((Tp(Z)/2)*log(Tp(Z)/(2*Pi))-Tp(Z)/2-Pi/8))

a =

(Z)->sqrt((real(Z)/2+Pi*t/8)/(2*Pi))

al1 =

(S)->1/(2*S)+1/(S-1)+(1/2)*log(S/(2*Pi))

p =

(Z)->1-2*(a(Z)-M(Z))

sig =

(Z)->real(sp(Z))

sp =

(Z)->(1-imag(Z))/2+I*real(Z)/2+I*Pi*t/8

1 March, 2018 at 1:24 pm

AnonymousWould it make sense to record that code in a new Pari/GP directory in the github project, next to the existing julia, maple, matlab, and python directories?

1 March, 2018 at 2:21 pm

David Bernier (@doubledeckerpot)I believe so, or maybe. It’s my current best effort at coding the mathematical functions for the effective approximation, as written up by Terry on the Wiki. It doesn’t have everything, but it has the definitions needed to calculate the effective approximations.

1 March, 2018 at 5:37 pm

Terence TaoThanks for this! I think we can now be fairly confident in the accuracy of the formula for the refined effective approximation , thanks to everybody for helping out with the debugging process. I’ve also put a text file with David’s PARI code into the git repository.

1 March, 2018 at 1:31 pm

David Bernier (@doubledeckerpot)This is what I get for , in the non-effective type estimates:

160 0.174873661533

320 0.278624615745

480 0.167598495339

640 0.165084846603

800 0.201954876756

960 0.103387669714

1120 0.0767779295558

1280 0.132886551163

1440 0.0802159981813

1600 0.0777462698681

1760 0.0950946156489

1920 0.0629013452776

2080 0.0949328843573

2240 0.0591497767926

2400 0.0785798163298

2560 0.0621868667021

2720 0.0585282736442

2880 0.0787554869341

3040 0.0462460274843

3200 0.0963053589535

The PARI/gp session is still running, so we might cross-check a sample of

values…

[Data added to wiki, thanks. Looks like the accuracy of and is almost identical – T.]1 March, 2018 at 5:43 pm

Terence TaoI have tentatively calculated a fairly tractable and usable upper bound for the main error term at the end of http://michaelnielsen.org/polymath1/index.php?title=Controlling_H_t-A-B/B_0 . Explicitly, the bound is

where is any lower bound for that is greater than or equal to 100, , and . Actually one should just set for the best bound (eventually I’ll probably replace with throughout in the wiki calculations in fact, it is a legacy from a period in which I was not sure if the error estimates were going to be monotone decreasing in ). I don’t yet have the ability to easily calculate in maple, but using as a proxy it looks like is only worse than by a factor of two or so (see table at the end of the above link), and this looks promisingly small once goes above or so. Asymptotically, the last two factors in the above definition of are close to 1, and the remaining expression is basically the upper bound for coming from the fact that (equality should occur when is close to a discontinuity for , i.e. ).

In the end I didn’t quite use the suggestion of splitting the integration into small and large portions; instead it was more efficient to estimate various factors in the integrands by expressions of the form for not too large, which could then be absorbed into the gaussian factors in the f factor. The case of very large had to be treated separately but here was very large and negative and the contribution was in fact super-exponentially small from this case.

I’ll double check the derivation soon, and also start working on getting some usable upper bound on . If we have all that then it seems that by putting everything together we should be able to handle all past a certain point (e.g. , which corresponds to or so), leaving one with a range that looks (barely) within the range of numerical verification.

2 March, 2018 at 8:20 am

RudolphI get an exact match with your wiki table, the one that compares the normalised and . Also produced some graphs that illustrate how well the new bound actually works. The discontinuities that David spotted in the previous thread are well visible and appear to all stay within the bound.

Using :

For : https://ibb.co/d7zDv7

For : https://ibb.co/efY6F7

For : https://ibb.co/eYdZ2n

For : https://ibb.co/fjSu2n

For : https://ibb.co/gDsf8S

Also got some encouraging timing results for the oncoming numerical verification effort.

with the latest , now computes in Pari/gp in 32.2 ms, compared to the previous (with the vwf-integral) that required 87.9 ms. A step change improvement :)

[Linked to on wiki, thanks! -T.]2 March, 2018 at 10:58 am

arch1Thanks much for the graphs Rudolph. I see that one should be careful in drawing conclusions about the fine structure when eyeballing these. See e.g. x=[1200,10000] in graph 3, then in graph 2.

2 March, 2018 at 11:20 am

RudolphNote that the graph’s y-axis scaling reduces for higher x to be able to keep the differences visible. Eyeballing these graphs should just help reinforce the intuition and most certainly won’t provide any hard evidence :)

2 March, 2018 at 12:33 pm

arch1Yup thanks again.

2 March, 2018 at 9:39 am

AnonymousIs it possible to derive (for any fixed positive and sufficiently large ) a simple effective bound for which would decay to zero for large ?

It seems that such bound is sufficient to give an effective upper bound (i.e. an explicit function of ) on the real part of any nonreal zero of .

2 March, 2018 at 9:48 am

Terence TaoWe’re close to doing this I think. By the triangle inequality we have

All terms on the right hand side are known to go to zero as , and if we made the effort we could probably get enough effective bounds on all of these to produce an explicit rate. But this would probably not be the most efficient way to keep away from zero; in particular it seems useful to multiply by a suitable mollifier first before subtracting 1 in order to reduce the oscillation.

2 March, 2018 at 10:12 am

Polymath15, fifth thread: finishing off the test problem? | What's new[…] thread of the Polymath15 project to upper bound the de Bruijn-Newman constant , continuing this post. Discussion of the project of a non-research nature can continue for now in the existing proposal […]