Problem with numerical evaluation of QQBar.

[PeterLuschny]

Consider the program below. It runs until n = 44 and then silently gives up for no apparent reason.

Tested with version Nemo: 0.47.3, Julia 1.11.1 on Windows 11/23H2, and Mac Sonoma 14.4.1/M2.

using Nemo

RR = ArbField(1000)

function F(m)
    sum(RR(tanpi(QQBar(n) / (1 + 2 * m))^(2 * m)) for n in 0:m)
end

function aList(upto)
    for m in 0:upto
        i = unique_integer(F(m))
        if i[1] == true
            println(m, " ", i[2])
        else
            println(m, "Error")
        end
    end
end
aList(50)

[fingolfin]

What do you mean by "silently gives up" ?

For me it indeed "slows down" when computing step 45, but it successfully completes the loop (on a MacBook with M1 Max, macOS 12, with 64 GB of RAM).

[PeterLuschny]

OK, it did not complete the loop on my systems in any reasonable time, but the systems also did not have 64 GB of Ram.

What remains is the observation that even on better equipped systems a serious change of state occurs at this point, the cause of which is not clear.

Message ID: @.***>

[thofma]

It seems that for many values of n, m the following is fine, but then for this specific values it is hanging/taking a very long time:

julia> n, m = 43, 45;

julia> s = tanpi(QQBar(n) / (1 + 2 * m))^(2 * m);

julia> ArbField(10)(s) # hanging here. Replace 10 by anything else.

This in the end calls qqbar_get_arb. I think there are some heuristics when computing enclosures, maybe they are not optimal here. Maybe @fredrik-johansson knows.

@PeterLuschny You probobably know this, but it seems to be more efficient to do all computations with approximations? If I do

 function F(m)
    sum((tanpi(RR(n) / (1 + 2 * m))^(2 * m)) for n in 0:m)
end

then everything is pretty fast (you might have to increase the precision for large m).