Is this in practice not a breaking change? I.e. if you only define (real) numbers, and use the basic arithmetic operators? Also if you use more e.g. the complex type and all operation, at least defined in standard Julia? An SpecialFunctions.jl?
I see e.g. one (seemingly obscure exception):
I was looking at what’s actually breaking (in the underlying library):
https://flintlib.org/doc/history.html#flint-3-0
The C++ interface (flintxx) has been removed. This interface is now maintained in the separate repository GitHub - flintlib/flintxx: C++ interface to FLINT (maintenance only) (Edgar Costa).
That’s of no concern to Julia(?).
There are also minor changes in the C interface, but you’re not exposed top that if you limit yourself to the Julia wrapper, I think. Though since it’s included fron FLINT_jll, I think you could actually call the C interface bypassing the Julia interface (and nothing stopping that such can be done)
If you had used the old C interface, then that might also be breaking then, but there’s no good reason do do such?
@JeffreySarnoff
Is the new version better in some sense, e.g. faster? Should it be used instead of ArbNumberics.jl (which still uses older Arb_jll that should still work).
I believe it may add some features, I’m thinking e.g. if you had just used ArbFloat from it.
I suppose Arb.jl is a little lighter dependency if you don’t need the add-ons. Should ArbNumerics.j wrap your library rather than Arb_jll (or FLINT_jll)?
Do both libraries default to the same precision, that I believe may be the underlying default? Which is lower than for MPFR (but can be set to same or higher)?
Arblib (like ArbNumerics) should be faster than Julia’s BigFloat in almost all cases, even at the same precision, certainly always faster with its default.
Though absolute fastest (if you only need larger than Float64):
It only supports basic arithmetic (not trigonometric), should always be accurate if I understood correctly, though doesn’t propagate NaNs or Infs.