Wrong or outdated claim, and suggestion

[PallHaraldsson]

Hi,

Is your claim about ArbFloat here:
@JeffreySarnoff
https://github.com/JeffreySarnoff/ArbNumerics.jl

slower than BigFloat wrong (and also slower than your type)? Is it only about QR? I understood ArbFloat to be faster usually, even at the same precision, but not always.

Of course it is faster than BigFloat on its default, but that's sort of unfair. I guess your 106 bit case is best case, and at higher ArbFloat wins. Many default to BigFloat after Float64, since they don't know better, why I intend to get that package documented, and now likely your package too.

Since you define all the basic operators, you could define all, just not yet done? That's a pro of ArbNumerics, also interval option.

I'm thinking should it add your package as a dependency? Could it use your type unless you ask for some inconvenient/large precision, then fall back to its implementation? And then your type could get the transcendentals that way?

[JeffreySarnoff]

Values of type ArbFloat{p} have precision p and lets say values of type BigFloat{p} have precision p.
In a calculation where all ArbFloat variables and all BigFloat variables have the same precision,
The ArbFloat version will outperform the BigFloat version with precision set at 64..4096 bits (at least).
Where the calculation involves elementary functions, the performance advantage is greater.
I am unaware of any real extended precision code where BigFloat types outperform ArbFloat types.
[and where the calculation involves Complex quantities -- ArbComplex is much more performant than Complex{BigFloat]]. The default precision of 106 bits was selected after much consideration of computational goals and requirements for the active community engaged in extended precision numerics -- there was no intent to pretend that 106 is the same as 256. Nonetheless, it is quite easy to establish either precision:
setprecision(BigFloat, 106) or setprecision(ArbFloat, 256).

What operators would you like to see added to ArbNumerics? [what do you find missing?]
In fact ArbNumerics provides many mathematical operations that BigFloats do not support.

[PallHaraldsson]

I think you're confirming it can't be 74% slower than BigFloat (maybe at some point it was), see in the table "69x slower" than in this package.

I don't know any missing in ArbNumerics, I mean over Base/BigFloat (and all packages add should work too, since based on those you provide). I meant they are missing in the package here, i.e. transcendental. The speed of the types here is possibly "missing" from your package. Why I mentioned combining, i.e. adding it as a dependency to your package. [Could also be done as a separate hybrid package, or even adding yours here.]

In fact ArbNumerics provides many mathematical operations that BigFloats do not support.

Intriguing. Such as (other than intervals)?

[dzhang314]

Hi @PallHaraldsson, thank you for your interest in MultiFloats.jl! I just re-ran the benchmark code posted in the README for MultiFloats.jl using the latest version of ArbNumerics, and I can confirm that on my workstation (Intel Core i9-11900KF), at 106-bit precision, ArbFloat is consistently slower than BigFloat.

Note that to run this code, the line using GenericSVD should now be replaced by using GenericLinearAlgebra, now that GenericSVD.jl is no longer maintained.

MultiFloat{Float64, 2}         |  qr  | 26.2 | 0.2895997
BigFloat                       |  qr  | 25.9 | 6.6063802
ArbFloat                       |  qr  | 25.9 | 14.8286139
Dec128                         |  qr  | 27.7 | 13.2876005
Double64                       |  qr  | 26.1 | 0.3890074
Float128                       |  qr  | 27.9 | 1.4353666
MultiFloat{Float64, 2}         | pinv | 26.0 | 1.6440293
BigFloat                       | pinv | 25.8 | 50.3552979
ArbFloat                       | pinv | -13.7 | 89.8766478
Double64                       | pinv | 25.9 | 2.2745036
Float128                       | pinv | 27.9 | 8.0112881

You can see that ArbFloat is about 2x slower than BigFloat and about 50x slower than my own Float64x2 type (which is an alias for MultiFloat{Float64, 2}). It also seems that ArbFloat has some kind of bug working with GenericLinearAlgebra.jl, which is causing it to produce a wrong answer in the pseudoinverse test. Note that all packages are being compared at 106-bit precision, with setextrabits(0) added for ArbFloat, so this is a fair apples-to-apples comparison.

Thus, as far as I can tell, my claims about performance are correct and up-to-date. If you run a similar benchmark with different findings, I would be interested to hear about the results.

The rest of the discussion appears to be about ArbNumerics.jl, not MultiFloats.jl, so I will close this issue.

[JeffreySarnoff]

ok -- ArbNumerics was never intended to be the answer for Linear Algebra. It is used with code that does heavy, high precision trig and more advanced math functions, particularly where results need assured bounds.