Author here. I will take the opportunity to advertise my blog at <a href="https://fredrikj.net/blog/" rel="nofollow">https://fredrikj.net/blog/</a> where I post occasional development updates about Arb and other projects.<p>Some improvements not covered in the 2016 preprint include much faster code for arithmetic and matrix multiplication (<a href="https://arxiv.org/abs/1901.04289" rel="nofollow">https://arxiv.org/abs/1901.04289</a>, <a href="https://fredrikj.net/blog/2018/07/high-precision-linear-algebra-in-julia-bigfloat-vs-arb/" rel="nofollow">https://fredrikj.net/blog/2018/07/high-precision-linear-alge...</a>), and code for rigorous arbitrary-precision numerical integration (<a href="https://arxiv.org/abs/1802.07942" rel="nofollow">https://arxiv.org/abs/1802.07942</a>, <a href="http://fredrikj.net/blog/2017/11/new-rigorous-numerical-integration-in-arb/" rel="nofollow">http://fredrikj.net/blog/2017/11/new-rigorous-numerical-inte...</a>).
For anyone wondering about the difference between endpoint-based interval arithmetic ([a,b]) and midpoint-radius ([m +/- r]) arithmetic (ball arithmetic): they are often interchangeable, but they have different tradeoffs. Roughly speaking, standard interval arithmetic is better for subdivision of space, while ball arithmetic is better for representing individual numbers.<p>A good technical introduction to ball arithmetic is this paper by Joris van der Hoeven: <a href="https://www.texmacs.org/joris/ball/ball.html" rel="nofollow">https://www.texmacs.org/joris/ball/ball.html</a>
Looks cool, but how does it get around the table-maker's dilemma? <a href="https://en.wikipedia.org/wiki/Rounding#Table-maker's_dilemma" rel="nofollow">https://en.wikipedia.org/wiki/Rounding#Table-maker's_dilemma</a><p><i>"No general way exists to predict how many extra digits will have to be carried to compute a transcendental expression and round it correctly to some preassigned number of digits. Even the fact (if true) that a finite number of extra digits will ultimately suffice may be a deep theorem."</i><p>My guess is they aim for convergence and it works well in practice but it's still unknown if that's guaranteed to be correct... is that right?
Relatedly, there's a relatively new julia package called MultiFloats.jl [1] for doing arithmetic with numbers of the form a_1 + a_2 + ... + a_n where a_{i+1} is of the order of the round off of a_i. So it's fixed precision, but the cool thing is you can easily generate code for arbitrary `n`. The package itself is just a few hundred lines of code. I've tried it on an NVIDIA GPU with fast double precision, and it seems to "just work" for basic linear algebra.<p>[1] <a href="https://github.com/dzhang314/MultiFloats.jl" rel="nofollow">https://github.com/dzhang314/MultiFloats.jl</a>
The library: <a href="https://github.com/fredrik-johansson/arb" rel="nofollow">https://github.com/fredrik-johansson/arb</a><p>LGPL
Arblib.jl [1] is a Julia wrapper for Arb. Most of the basic wrapping is auto-generated from Arbs documentation. There is still work left to make it interface well with the Julia ecosystem, and document it, but it's on it's way.<p><a href="https://github.com/kalmarek/Arblib.jl" rel="nofollow">https://github.com/kalmarek/Arblib.jl</a>
Whenever I encounter arbitrary precision libraries I want to try them out on extended Dudeney's digital century puzzle.<p>This is from TAOCP 4A part 1:<p>> Dudeney's Digital Century puzzle.) There are many curious ways to obtain
the number 100 by inserting arithmetical operators and possibly also parentheses into
the sequence 123456789. For example,
100 = 1 + 2 x 3 + 4 x 5 - 6 + 7 + 8 x 9 = (1 + 2 - 3 - 4 ) x (5-6-7-8-9) = ((1/((2 + 3)/4 - 5 + 6)) x 7 + 8) x 9.<p>Of course, instead of 100 we can put something else, add exponentiation, decimal point and an operator that reinterprets the number as if written in base X (12345_6789 = 2124962081444303 in base 10).<p>I also like how Knuth adds the number of possible trees in a grammar that generates these expressions without redundant parentheses :D