Regression in bubble integral?

[a-maier]

After having another look I suspect that #17 actually introduced a regression.

For the bubble integral with s = 0, m = 174 I get -10.3181 both before and after. For s = 125^2 I get

• -10.2273 with version 2.0.7
• -7.96775 with version 2.0.8

I can reproduce the 2.0.7 number from the analytic expression. It also looks more plausible to me. Since we are below threshold, the number should differ from the one at s = 0 by terms of order s/(4m^2) ~ 0.1.

[spj101]

I also think that #17 is a regression.

I think I would just prefer to set sgn = 1 and be done with it.

Explanation:
Looking at (4.23) in 0709.1075 we see that the only term that depends on r is (1/r-r)*log(r) with Im(r) = varep sign(r-1/r). This is correctly coded as:

(cone/x1-x1)*cLn(x1, Sign(Real(x1-cone/x1)))

The value of r (i.e x1) is determined by solving the quadratic equation (4.24) in 0709.1075 and is of the standard form bb ± rtt where picking + or - just swaps what we call r and 1/r. The expression is invariant under this replacement. Therefore, whether we choose the + or - sign is completely irrelevant (or a very subtle numerical optimisation, maybe the logarithm is slightly more precise/faster when called with x1 or cone/x1, I guess this would depend on the compiler).

However, the expression as coded now is wrong, because for real bb=m0+m1-s and (m0+m1-s)^2 - 4*(m1*m0) <= 0 (e.g. in the trigger_test example, or in @a-maier's example above) we have that rtt is pure imaginary and bb is pure real and thus Real(Conjg(bb)*rtt) = 0 and sgn = Sign(Real(Conjg(bb)*rtt)) = 0. We must have sign = ± 1 not 0, which is why the code is now returning wrong results.

[spj101]

I think that this was now resolved in 6226972 and version 2.0.9 gives the expected results:

double mu2 = 1.0;
vector<double> m = {174.0*174.0, 174.0*174.0};
vector<double> p = {125.0*125.0};
ql::Bubble<complex,double> bb;
bb.integral(res, mu2, m, p);
for (size_t i = 0; i < res.size(); i++) cout << "eps" << i << "\t" << res[i] << endl;

Gives

eps0	(-1.02272989444019302140986837912351e+01,1.30017362758835244201652477363495e-16)
eps1	(1.00000000000000000000000000000000e+00,0.00000000000000000000000000000000e+00)
eps2	(0.00000000000000000000000000000000e+00,0.00000000000000000000000000000000e+00)

Perhaps this issue can now be closed as resolved?