-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support base keyword as in Julia 1.8 #52
Comments
thank you |
Looking at the code: ArbNumerics.jl/src/libarb/ArbComplex.jl Line 73 in d34c8d1
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. 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 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. |
You might want to support the
base
keyword as in JuliaLang/julia#42428For
precision
, the simplest thing is to overloadBase._precision
instead ofBase.precision
, ifisdefined(Base, :_precision)
; that way you can re-use the logic fromBase
for handling thebase
keyword.In
setprecision
, you already accept abase
keyword, but only allowbase
of 2 or 10. You could instead handle it analogously toBigFloat
: https://github.com/JuliaLang/julia/blob/684de614ecb85dd55b076ec001eb88f44fbad5c8/base/mpfr.jl#L818-L823The text was updated successfully, but these errors were encountered: