Incorrect printing of error radius

[d0sboots]

$ ./bin/pip list |grep flint
python-flint            0.7.1

$ ./bin/python
Python 3.13.3 (main, Apr 10 2025, 21:38:51) [GCC 14.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from flint import *
>>> ctx.prec=54
>>> repr(arb.pi())
'[3.14159265358979 +/- 3.45e-15]'
>>> repr(arb.pi()-arb.pi())
'[+/- 2.23e-16]'
>>> repr(arb.pi().rad())
'[1.11022302462516e-16 +/- 3.46e-31]'
>>> repr(arb.pi().rad().rad())
'0'

As you can see, the radius is clearly being printed incorrectly. This is a result of flintlib/flint#2208 and flintlib/arb#391.

This is arguably an issue in flint itself, but arguably also a difference in semantics between flint and python. In this case, repr needs to round-trip values, so it needs to be using the ARB_STR_MORE flag.

[oscarbenjamin]

It is possible to deconstruct an arb exactly into 4 integers. I can't remember if there is a way with python-flint to get directly back to the same arb from the 4 integers but it would be useful to have that:

In [26]: a = flint.arb.pi()

In [27]: ints = a.mid().man_exp() + a.rad().man_exp()

In [28]: ints
Out[28]: (884279719003555, -48, 1, -52)

If you could create an arb from these 4 integers like arb(1,2,3,4) or arb((1, 2, 3, 4)) then it could be displayed as one representation perhaps with the mantissa as a hex Python literal:

arb(0x1, 2, 3, 4)

[oscarbenjamin]

It is arb((1, 2), (3, 4)):

In [3]: a = flint.arb.pi()

In [4]: a
Out[4]: [3.14159265358979 +/- 3.34e-15]

In [5]: flint.arb(a.mid().man_exp(), a.rad().man_exp())
Out[5]: [3.14159265358979 +/- 3.34e-15]

It could be:

In [14]: from flint import arb

In [15]: def arb_repr(a):
    ...:     mm, me = a.mid().man_exp()
    ...:     rm, re = a.rad().man_exp()
    ...:     return f'arb(({hex(mm)}, {me}), ({rm}, {re}))'
    ...:

In [16]: a = arb.pi()

In [17]: a
Out[17]: [3.14159265358979 +/- 3.34e-15]

In [18]: arb_repr(a)
Out[18]: 'arb((0x3243f6a8885a3, -48), (1, -52))'

In [19]: arb((0x3243f6a8885a3, -48), (1, -52))
Out[19]: [3.14159265358979 +/- 3.34e-15]

[d0sboots]

There is also already the pretty-print setting, which could control which is used by default.

[oscarbenjamin]

Since that currently fails with an error I guess it is safe to change it:

In [10]: flint.ctx.pretty=False

In [11]: flint.arb(10)
Out[11]: ---------------------------------------------------------------------------
AttributeError: 'flint.types.arb.arb' object has no attribute '_repr_str' 

[oscarbenjamin]

I don't remember what the size constraints are on the 4 different integers. Is it worth using hex for any of the others or is just the mantissa fine?

Note that CPython will fail to evaluate a decimal integer literal with more than 4300 decimal digits:

In [21]: eval('1'*4301)
Traceback (most recent call last):
...
SyntaxError: Exceeds the limit (4300 digits) for integer string conversion: value has 4301 digits; use sys.set_int_max_str_digits() to increase the limit - Consider hexadecimal for huge integer literals to avoid decimal conversion limits.

[oscarbenjamin]

These fail:

In [7]: eval(str(flint.arb((10, 10**20000)).man_exp()))
Traceback (most recent call last):

In [15]: eval(str(flint.arb((1, 2), (10, -10**20000)).rad().man_exp()))
Traceback (most recent call last):

I guess mid mantissa and both exponents can be large. Only the rad mantissa is small. May as well use hex for all 4 integers:

In [20]: arb_repr(flint.arb(3))
Out[20]: 'arb((0x3, 0x0), (0x0, 0x0))'

In [21]: arb_repr(flint.arb(10))
Out[21]: 'arb((0x5, 0x1), (0x0, 0x0))'

In [22]: arb_repr(flint.arb(10).exp())
Out[22]: 'arb((0x15829dcf95055f, -0x26), (0x20700001, -0x43))'

In [28]: a = flint.arb(10).exp()

In [29]: a
Out[29]: [22026.4657948067 +/- 1.80e-11]

In [30]: arb_repr(a)
Out[30]: 'arb((0x15829dcf95055f, -0x26), (0x20700001, -0x43))'

In [31]: eval(_)
Out[31]: [22026.4657948067 +/- 1.80e-11]

[oscarbenjamin]

It looks like the code in arb.repr was already intended to do this but is just incomplete and doesn't work.

It is a bit trickier because obviously need to handle nan and inf and the error part can be omitted if it is exact. That is not super hard but this is a bigger problem:

In [13]: a = arb((1,2),(3,4))

In [14]: a.repr()
Out[14]: 'arb((0x1, 0x2), (0x30000001, -0x18))'

In [15]: eval(_).repr()
Out[15]: 'arb((0x1, 0x2), (0x18000001, -0x17))'

In [16]: eval(_).repr()
Out[16]: 'arb((0x1, 0x2), (0x30000003, -0x18))'

In [17]: eval(_).repr()
Out[17]: 'arb((0x1, 0x2), (0xc000001, -0x16))'

It seems that arb_add_error modifies the radius in a non-idempotent way so constructing the radius from two ints does not precisely round trip from a.rad().man_exp(). It seems like pretty much all mag_set/mag_get functions do this intentionally.

I'm not sure if any functions apart from arb_dump_str could give a full round trip.

[fredrik-johansson]

IIRC mag_set_fmpz_2exp_fmpz will preserve the mantissa (provided it's smaller than 2^MAG_BITS).

[oscarbenjamin]

Thanks. That looks right from the code and seems like the behaviour wanted here.

I think an arb should construct exactly from ints apart from bringing the radius mantissa into range. That already happens for other ints regardless of prec which seems correct like Decimal:

In [27]: flint.ctx.prec = 10

In [28]: flint.arb(2**20 + 1)
Out[28]: [1.0e+6 +/- 4.86e+4]

In [29]: flint.arb(2**20 + 1).repr()
Out[29]: 'arb((0x100001, 0x0))'

It would be nice to have a different pretty display for exact arbs. I have seen many people get confused by the +/- even though the arb is exact. Perhaps something like:

1.0...e+6

[oscarbenjamin]

Should be fixed after gh-300 although I did not test this exhaustively.

In about 30 minutes the nightly wheels here will update (check the upload time):
https://anaconda.org/scientific-python-nightly-wheels/python-flint

You can install from the instructions at the top there to test this. Let us know how you get on.