Open saraedum opened 2 years ago
Since arb_unit_interval
prints as [0.500000 +/- 0.501]
there seems to be something systematic going on here that I am missing.
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.
It might be worth to fix this so such constants print more nicely. @fredrik-johansson any opinion here?
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.)
The following code produces the output
[+/- 1.01]
.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.)