arb_zero_pm_one prints as [+/- 1.01] instead of [+/- 1.00]

[saraedum]

The following code produces the output [+/- 1.01].

#include <arb.h>

int main() {
  arb_t x;
  arb_init(x);
  arb_zero_pm_one(x);
  arb_printn(x, 64, 0);
  arb_clear(x);
}

Since internally this corresponds to the ball [+/- 1], I would have expected this to print [+/- 1.00].

Is there a reason why [+/- 1.01] would be the correct output here?

(I produced this output with arb 2.20 as packaged on conda-forge.)

[saraedum]

Since arb_unit_interval prints as [0.500000 +/- 0.501] there seems to be something systematic going on here that I am missing.

[albinahlback]

Looking at the documentation for arb_printn (https://arblib.org/arb.html#c.arb_printn), it refers us back to arb_get_str where we see that

With default flags, the output can be parsed back with arb_set_str(), and this is guaranteed to produce an interval containing the original interval x.

In other words, the radius when converted to decimal has to be greater or equal to the radius in binary. I believe it just does not check if the interval can be converted without loss of precision (like 0.5 can be converted without loss, but 0.3 can't be converted back and forth without loss), and thus always guards itself against loss of precision by adding some small number to the radius.

[saraedum]

It might be worth to fix this so such constants print more nicely. @fredrik-johansson any opinion here?

[saraedum]

Note that this came up while working on a Python wrapper for Arb. In an interactive Python/SageMath session it's just odd to type pm_one and get an output that is apparently wrong. (Though what's printed is of course not what's stored internally.)

[d0sboots]

I just stumbled across this in a particularly harsh way. I was also using the Python wrapper (python-flint); in that context, it is expected that repr of an object accurately represent the object in a way that (typically) can be round-tripped, and the radius is very very far from this right now. Here's a quick test (using Flint directly) showing how the radius can be off by > 4x:

#include <stdio.h>
#include "flint/arb.h"

int main() {
  arb_t x;
  arb_init(x);
  arb_const_pi(x, 54);
  printf("Pi: ");
  arb_printn(x, 20, 0);
  printf("\nTrue precision: %g\nAfter cancellation: ", mag_get_d(arb_radref(x)));
  arb_sub(x, x, x, 54);
  arb_printn(x, 54, 0);
  printf("\n");
  arb_clear(x);
  return 0;
}

Pi: [3.141592653589793 +/- 4.50e-16]
True precision: 1.11022e-16
After cancellation: [+/- 2.23e-16]

This shows the seeming nonsensical result I was faced with, where cancellation of two values improves the error bound.

---

I understand why flint is printing what it does; there is a tension between "print the error radius of the result" and "print the error radius of the decimal string," and flint chooses the latter. Similarly, given the choice between "print the most digits that are known to be correct" and "print enough digits to reproduce the result," flint chooses the former. But the combination of those choices leads to awkward default behavior, where the radius is always ~within an order of magnitude correct, but never actually correct when printed (unless extra care is taken).