support base keyword as in Julia 1.8

You might want to support the base keyword as in JuliaLang/julia#42428

For precision, the simplest thing is to overload Base._precision instead of Base.precision, if isdefined(Base, :_precision); that way you can re-use the logic from Base for handling the base keyword.
In setprecision, you already accept a base keyword, but only allow base of 2 or 10. You could instead handle it analogously to BigFloat: https://github.com/JuliaLang/julia/blob/684de614ecb85dd55b076ec001eb88f44fbad5c8/base/mpfr.jl#L818-L823

thank you

Looking at the code:

Line 73 in d34c8d1

    
           function ArbComplex(x::T; bits::Int=0, digits::Int=0, base::Int=iszero(bits) ? 10 : 2) where {T<:Real}

while you allow base-10 it seems to be only to calculate precision (number of fractional bits you store), i.e. 0.1 is still not exact, nor is 1/3 etc. (yes you get very close...).

Neither is 1/3 exact for DecFP or BigFloat. It seems neat if it would be, and yes, rationals are for that, but slow. I'm guessing the base-2 is very ingrained in you package (and BigFloat). Would it be possible to allow true arbitrary base or at least a few (or one) chosen ones? Do you know of any package with base-30 or even base-2007835830 (i.e. for 2357911131719*23)?

DecFP is base-10, or actually base-1000, for 1000/1024 = 97.7% of bit patterns used (for the mantissa)

Why base-2007835830? It's 93.4% of 31-bit numbers but only 46.7% of valid 32-bit patterns. That seems low, but am I incorrect in viewing that efficiency as log2(2007835830)/32 = 96.7%? It also seems 32-bit alignment could be helpful.

The Arb C library encodes values using extended Radix 2 representations.
What would you prefer that base=2 and base=10 make happen.

Arbitrary bases are not low-hanging fruit, digit by digit equivalences falter easily (fractional digit elements when interconverting is one cause). Of course, it is possible to add a field to the representation, one that carries the radix along with the precision and the midpoint and the half-interval. There is good reason not to do this -- it would mean adding a layer of struct refinement above or betwixt the Arb C library structs <--> Julia interoperable structs. That is a time waster unless a very comprehensive redesign is undertaken. There are likely better returns on other coding investment with Arb <--> Julia. If the base were to be available at once and for all calculation (until it change), then we run into the problems with a shared active precision that have made BigFloat less wonderful.

I am happy to continue the conversation.

fyi the dual conversions (base=10 into base=2, base=2 into base=10) are designed not to be as very nearly inversive as theoretically possible. After much experimentation, I chose to protect the veracity of the Radix 2 valuations even over Radix 10 conversion and back again. Only one of the two bases can be preferentially distinguished in this way. So whatever inexactitude exists is strategic.