Misunderstanding about printing of `ArbElem`s

[JohnAAbbott]

Here is some OSCAR code (for computing a recurrence relation, published by J-M Muller):

RR = real_field();
BIT_PREC = 233;
set_precision!(Balls, BIT_PREC);

Vprev = RR(2);
Vcurr = RR(-4);
Vprev += RR(2)^(1-div(75*BIT_PREC,100));
for i in 1:8+div(2*BIT_PREC,11)
  Vnext = 111 - 1130/Vcurr + 3000/(Vcurr*Vprev);
  Vprev = Vcurr;
  Vcurr = Vnext;
  println("Vcurr = $(Vcurr)");
end

The printed values of Vcurr include the following:

Vcurr = [6.2 +/- 0.0608]
Vcurr = [+/- 9.06]
Vcurr = [+/- 48.2]
Vcurr = [+/- 1.07e+2]
Vcurr = [1e+2 +/- 5.68]

Do the three central intervals contain zero or not? If they do, why do I not get a "division by zero" error?
OSCAR version: 1.7.0-DEV #master a3f6b0d 2025-12-10

[thofma]

Have you checked whether they contain zero? There is a contains function.

P.S.: The printing for elements of RR is not faithful, which can be misleading if they have low relative accuracy. You can look midpoint() and radius(), which often looks more helpful in such cases.)

[JohnAAbbott]

Have you checked whether they contain zero? There is a contains function.

P.S.: The printing for elements of RR is not faithful, which can be misleading if they have low relative accuracy. You can look midpoint() and radius(), which often looks more helpful in such cases.)

Ahh, I see. It seemed to me that [+/- 9.06] would indicate an interval containing zero. Maybe there should be some documentation explaining how one should read the printed form; it would certainly be nice if the printed form could make it immediately clear whether zero is contained or not... not sure how easy that would be.

[thofma]

An explanation like the one here: https://docs.oscar-system.org/stable/Nemo/real/#Printing?

[JohnAAbbott]

Yes, I had seen that "explanation", but did not feel wiser afterwards. The printing is weird:

julia> ball(RR(10),RR(7))
[1e+1 +/- 7.01]

julia> ball(RR(10),RR(8))
[1e+1 +/- 8.01]

julia> ball(RR(10),RR(9))
[+/- 19.1]

What does the midpoint does not have a greater exponent than the radius in its scientific notation mean? In particular, I am uncertain as to what scientific notation might mean in this context - in decimal, in binary, or...? I wonder why (strictly) greater rather than greater than or equal to

[thofma]

The printing magic is

function native_string(x::arb)
  d = ceil(parent(x).prec * 0.30102999566398119521)
  cstr = @ccall libflint.arb_get_str(x::Ref{arb}, Int(d)::Int, UInt(0)::UInt)::Ptr{UInt8}
  res = unsafe_string(cstr)
  @ccall libflint.flint_free(cstr::Ptr{UInt8})::Nothing
  return res
end

which I think was contributed by @fredrik-johansson.

@fredrik-johansson do you know if there is some variation of this magic, which would make

julia> ball(RR(10),RR(9))
[+/- 19.1]

print more like

julia> ball(RR(10),RR(9))
[1e1 +/- 9.1]

?

[JohnAAbbott]

I also find it odd/confusing that the printed form is usually [midpoint +/- radius] but under some circumstances the first part is omitted and then after +/- the value printed is (presumably) abs(midpoint)+radius. That seems like some pretty contorted logic to me...

[fredrik-johansson]

The default logic is that midpoint digits are shown only if they are correct (up to 1 ulp error, due to the table-maker's dilemma).

Thus 10 +/- 9 will not print any digits because the leading digit could be anything from 1 to 9.

You can force more digits with the ARB_STR_MORE flag.

[JohnAAbbott]

The default logic is that midpoint digits are shown only if they are correct (up to 1 ulp error, due to the table-maker's dilemma).

Thus 10 +/- 9 will not print any digits because the leading digit could be anything from 1 to 9.

You can force more digits with the ARB_STR_MORE flag.

1 ulp in which base? I thought the table-maker's dilemma was about achieving 0.5 ulp.
Here are some examples (generated inside Oscar):

julia> ball(RR(10),RR(8))
[1e+1 +/- 8.01]

julia> ball(RR(10),RR(8.1))
[1e+1 +/- 8.11]

julia> ball(RR(10),RR(8.9))
[1e+1 +/- 8.91]

julia> ball(RR(10),RR(8.9999))
[+/- 19.0]

julia> ball(RR(10),RR(8.999))
[1e+1 +/- 9.00]

julia> ball(RR(10),RR(8.999899983406))
[1e+1 +/- 9.00]

It still seems very odd to me that when no digits of the midpoint are printed then after the +/- we no longer see the radius, but some other value instead... I'd almost prefer [??? +/ 9.01] to [+/- 19.0], though to be honest neither of those conveys much useful information to the reader. e.g. [10.00 +/ 9.01] would make it clear to the reader that the interval is positive.
Maybe the 1-ulp rule should be relaxed? 5-ulp? 9-ulp? Does it even make sense to display the radius with more precision than the midpoint? I'm really quite confused by the design choices here.