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.
105 comments
Comments feed for this article
24 February, 2018 at 10:25 am
Terence Tao
A 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 Tao
To 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 Tao
On 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
Anonymous
this 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
with imaginary part 0.4, as shown
when I take a
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 Tao
Yes, 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
Anonymous
Is 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 Tao
My 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
Anonymous
In 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
Anonymous
Another 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 Tao
It 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
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
KM
I 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
Anonymous
Some 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
Vsevolod
Quite 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
Rudolph
David,
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
Rudolph
Oops. 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 Tao
Actually, 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 Tao
I 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 Tao
It 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 Tao
Here is a lemma that may be useful.
Lemma Let
be real numbers for
with
and
. Let
be a real number, and suppose that
Then one has
whenever
.
Remark The condition (1) improves a little bit upon the condition
that 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).
Proof It suffices to show that for any real phase
, the quantity
is 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
KM
Using 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 Tao
Thanks 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
KM
I 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 Tao
KM, 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
KM
Thanks, 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 Tao
Ah, I made a stupid typo in my own code. I can now confirm your value of
for
.
27 February, 2018 at 11:59 am
KM
I 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 Tao
Gah, 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
KM
Custom 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 Tao
Great! 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
Anonymous
I 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
KM
Actually, 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
Rudolph
I 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:
doesn’t oscillate, hence to embrace
I used
.
C-error term for lower
yet, I still used it to produce the plots (also since the match with
at lower
was pretty good).
and
move away from zero.
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
?
1) The line
2) I appreciate that the Ht-ABC-formula has been deprecated now, however since we don’t have an effectively bounded
3) The data looks encouraging for the problem at hand. Distributions clearly tend to convergence towards more ‘normal’ shapes with increasingly emptier ‘tails’, when
4) I wonder whether it is correct to say that when the distribution for
Couldn’t resist a philosophical note :)
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…
The paraphrased Newman-quote: ‘RH if true, then it is barely so’ is also illustrated by the plots. When
27 February, 2018 at 10:51 am
Anonymous
Hah! That Newnan quote is ‘barely’ rubbish.. And RH is true! 😄
27 February, 2018 at 4:29 pm
Terence Tao
Nice 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
Rudolph
You 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 Tao
In 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 Tao
p.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 Tao
Thanks 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 Tao
Thanks 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 Tao
Is 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
Rudolph
For 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
Anonymous
I 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.
, slightly different w.r.t.
and
, and really different for
:
I seem to get the same thing as you 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 Tao
Ah, 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
Rudolph
I 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
Anonymous
Again 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
Anonymous
There’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
Anonymous
imaginary 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 Tao
Thanks 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
Rudolph
Good 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 Tao
Well, 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
Anonymous
Sorry 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
Anonymous
For
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
Rudolph
Also 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 Tao
It 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
Rudolph
You’re right! It should be
indeed, apologies for the false alarm.
1 March, 2018 at 7:34 am
Rudolph
A 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 Tao
From 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
Anonymous
I 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
Anonymous
This 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 Tao
Not 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
anonymous
It’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 Tao
This is a promising approach! I will try it and see what I get.
27 February, 2018 at 12:15 pm
Anonymous
On the wiki page for this test problem, should the second
be
?
[Corrected, thanks – T.]
27 February, 2018 at 1:29 pm
Anonymous
I 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
Anonymous
If 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 Tao
It 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 Tao
I 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
KM
For 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
KM
Also 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 Tao
Good catches! I have corrected the wiki accordingly.
27 February, 2018 at 6:41 pm
Anonymous
In 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 Tao
Just 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).
and
do not affect values of
…
As far as I can tell, the corrected
1 March, 2018 at 5:21 pm
Terence Tao
Thanks 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.
, the normalized errors of
compared to the integral formula are likely a bit smaller.
, for z=1600, I now get a normalized error of 0.000439823 (versus 0.000488248 on the wiki).
With the corrected
For example, with the corrected
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
Anonymous
David 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
anonymous
When 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
Anonymous
Would 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 Tao
Thanks 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 Tao
I 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
Rudolph
I 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.
[Linked to on wiki, thanks! -T.]
2 March, 2018 at 10:58 am
arch1
Thanks 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
Rudolph
Note 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
arch1
Yup thanks again.
2 March, 2018 at 9:39 am
Anonymous
Is it possible to derive (for any fixed positive
and sufficiently large
) a simple effective bound for
which would decay to zero for large
?
) on the real part of any nonreal zero of
.
It seems that such bound is sufficient to give an effective upper bound (i.e. an explicit function of
2 March, 2018 at 9:48 am
Terence Tao
We’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 […]