Explanation for printing of real balls is... lacking

[fingolfin]

In real.md it says:

Printing real balls can at first sight be confusing. Lets look at the following
example:

... and then proceeds to "explain" why a value that is constructed as 1 +/- 2 is printed as +/- 3.01:

The first reason that c [sic, should be x] is not printed as [1 +/- 2] is that the
midpoint does not have a greater exponent than the radius in its scientific
notation. For similar reasons y is not printed as [12 +/- 2].

That isn't really a reason from where I stand, more a statement of facts. But more important it doesn't really explain what the rules are, so I still wouldn't be able to predict how any other such elements would be printed...

The second reason is that we get an additional error term after our addition. As we
see, radius(c) is not equal to $2$, which when printed rounds it up to a
reasonable decimal place. This is because real balls keep track of
rounding errors of basic arithmetic.

This second "reason" seems to be completely unrelated to how x is printed, but instead talks about how radius(x) is printed (I think? Maybe?).

All in all, these explanations left me personally with more questions than I started with. Of course I may just be particularly daft and it is crystal clear for others, but I'd still appreciate if we could improve this section -- well, I can't, as I still have no idea what's going on. My next step would be to try and find out if e.g. the arb documentation explains this better.

[tthsqe12]

The real reason is that arb is deathly afraid of printing "wrong" digits in the midpoint. A corollary of this is that if the interval contains zero, then there are no significant digits to print in the midpoint, and so the printed midpoint is forced to zero. Then, it would also be "wrong" if the printed interval didn't contain the original interval. Hence 1+-2 ends up as 0+-3.