Your package(s) getting outdated?

[PallHaraldsson]

with @dzhang314's https://github.com/dzhang314/MultiFloats.jl

I assume you know of it, but asking/pointing to, to make sure.

I believe it has the same exact representation as you have (same exact API too, only type name different?), the only question is the yellow sign for "transcendentals sin, exp, log"

He uses MPFR for it so I'm not sure why that sign (some bug seemingly), and I though he could use your code (for the Float63x2 case, or ArbFloat for generally), or alternatively, you could use his. I.e. should this package depend on MultiFloats.jl to use its speed and your transcendentals functions to make it complete at least for the double-double case?

all the arithmetic, including sqrt, is accurate I believe in all the packages; but you support transcendentals, meaning available, not fully accurate? I mean, I believe some functions can't be accurate because of the "table maker's" dilemma".

I've been looking into correctly rounded math, and it's possible for Float32, not in general for even Float64, but getting better there, too large a search space to confirm. I don't think Julia provides the best libm (or pure Julia replacement) for correctly rounded math (there's no longer a speed-accuracy tradeoff if I recall), or best approximation, and it could document more what's it does achieve.

I've discussed with you before that Julia should drop BigFloat, as redundant with your better package(s), and now with this even newer I discovered only today.

I see you both have same number of correct digits 26.0 vs 25.9 vs 27.9. It might seem strange to count fractional digits. Isn't it about integer number of binary correct digits, then converted to base 10? Still strange to me to hit 26.0 exactly...

[dzhang314]

Hi @PallHaraldsson,

As the author of MultiFloats.jl, I can tell you there are some important things DoubleFloats.jl does that my package does not do.

• DoubleFloats.jl has explicit checks for Inf/NaN to correctly propagate these values. MultiFloats.jl makes no attempt to do this, which causes Inf to collapse into NaN (in effect, there is a single "error" value that encompasses both Inf and NaN). This is a fundamental design tradeoff (speed vs. IEEE conformance) and both choices are valid. Dropping the Inf/NaN checks makes MultiFloats.jl faster at the cost of not supporting some use-cases.

• DoubleFloats.jl has faster transcendental functions, implemented purely in terms of Float64 operations, that don't call into MPFR. This is a serious advantage; converting into and out of the MPFR format is slow and not thread-safe (due to some issues in BigFloat outside of my control). MultiFloats.jl is faster in applications like linear algebra where transcendentals are rare; for applications with lots of transcendentals, DoubleFloats.jl is faster. (I do eventually want to solve this for MultiFloats.jl, but doing this correctly for triple-float and above requires solving some research-level questions.)

• Dropping BigFloat is a bad idea for two reasons: (1) MPFR makes correct rounding guarantees, which is important if you want exact bit-for-bit reproducibility. (2) MPFR is far superior when you want to compute with huge numbers with many thousands to millions of bits (e.g., computational number theory). Libraries based on floating-point expansions, like DoubleFloats.jl and MultiFloats.jl, are faster in the intermediate range (100-400 bits) but will likely never compete in the extreme range (10000+ bits) due to fundamental floating-point vs. integer limitations.

So, DoubleFloats.jl, MultiFloats.jl, and BigFloat all make different design decisions, making all three valuable libraries for different use cases. Although you are correct that the speed-accuracy tradeoff has been largely solved for Float32/Float64, at higher precision there remains a challenging landscape with no single correct answer.

Hopefully, future research (like the techniques I'm working on!) will eventually lead to convergence among these approaches, but at this time, there is still a lot of room for different libraries to make different decisions.

[PallHaraldsson]

DoubleFloats.jl has explicit checks for Inf/NaN to correctly propagate these values. ... Dropping the Inf/NaN checks makes MultiFloats.jl faster at the cost of not supporting some use-cases.

Yes I noticed something on that, otherwise they have identical results? So he can't simply depend on your package, though he could and check if NaN and then recover Inf if it applied? I'm not sure if then dropping the speed advantage. Branches are slow, but only taken branches?!

Dropping BigFloat is a bad idea for two reasons: (1) MPFR makes correct rounding guarantees, which is important if you want exact bit-for-bit reproducibility. [You have that with DoubleFloats already?!] ... Libraries based on floating-point expansions, like DoubleFloats.jl and MultiFloats.jl, are faster in the intermediate range (100-400 bits) but will likely never compete in the extreme range (10000+ bits) due to fundamental floating-point vs. integer limitations.

I mean drop BigFloat/MPFR as stdlib, since it's a non-small dependency most do not use. It's of course still useful for some, and still I just think a lot of people overlook the better packages, just because BigFloat is available, and don't really need more than 100-400 bits (also BigFloat is also 256 bits by default, though you can change), and maybe perceived Bitfloats as the only larger option, or even fastest. I mean drop BigFloat as a type/stdlib, it would still be available in a non-stdlib package. With using MPFR or using BigFloat, or using Julia1 or whatever would be decided to recover it.

[dzhang314]

So he can't simply depend on your package, though he could and check if NaN and then recover Inf if it applied?

True, there could be a bit of code-sharing there, but I think the amount is relatively small (~200 lines for the core Float64x2 arithmetic operations) and I occasionally make breaking changes to the core of MultiFloats.jl. There was a huge reorganization to support SIMD.jl Vec types in v2.0, and I'm about to totally rip it up again to support a new class of faster renormalization-free arithmetic algorithms in v3.0. So introducing a dependency in either direction is probably not worth it while I'm still conducting research and large changes are happening.

I mean drop BigFloat/MPFR as stdlib, since it's a non-small dependency most do not use.

That's an interesting point, and I definitely agree that the presence of BigFloat/MPFR hides the visibility of other high-precsion packages. But taking a type out of Base would definitely be a breaking change gated behind a major version bump.

For what it's worth, I think BigFloat/MPFR is a good first choice because its limitations are easy for a new user to understand -- it works the way you'd expect, it's just slow. Both DoubleFloats.jl and MultiFloats.jl have some strange gotchas (mostly coming from the variable-precision gaps between the limbs) that are highly worthwhile when you need the speed, but can cause some unexpected failure modes if you're not used to programming robustly around them.