Document BigFloat replacement; ArbFloat

[PallHaraldsson]

[skip ci]

[oscardssmith]

is it true that for basic operations ArbFloat is faster than BigFloat?

[adienes]

given that GMP based floats are 1. integrated directly into Base instead of an external package and 2. extremely well known and a global standard, I vote 👎 on recommending a non-"official" package in Base documentation, especially with such strong claims

that's not to say that community-driven package curation and recommendation for more niche (and possibly indeed better!) replacements to common tools can't be useful, but I don't think it belongs in base/numbers.md

[andrewjradcliffe]

There are a couple things problematic here.

1. The behavior of arblib wrt floating point numbers is not quite identical to that of MPFR (e.g. -0.0 not supported). Unless your algorithm depends on sign of arguments, and does not examine magnitude, then such a difference would not matter.
2. Despite enthusiasm for arblib, documentation needs to present a measured perspective. "very fast, much faster than BigFloat" fails to satisfy such a constraint, and, perhaps more importantly, states a quantitative conclusion for which supporting data does not exist. Note that I would be glad to see said supporting data.

[PallHaraldsson]

is it true that for basic operations ArbFloat is faster than BigFloat?

Yes, I believe so, since:

The underlying C library calculates more rapidly than BigFloat at any precision.

I believe that translates to ArbFloat (or I would be curious if not, and why); and I asked:
JeffreySarnoff/ArbNumerics.jl#63

in addition:

Initially, the default precision is set to 106 bits. All ArbNumeric types use the same default precision. You can change this to e.g. 750 bits

so it's of course much faster with it's default, which can be changed (or for BigFloat).

1. The behavior of arblib wrt floating point numbers is not quite identical to that of MPFR (e.g. -0.0 not supported)

@JeffreySarnoff, I did not know that, and then I might have toned down the recommendation. Still is -0.0 very valuable? Also ArbNumerics.jl has interval capability, so that package is superior in that way. I think it's very valid to document it as an alternative in some way.

given that GMP based floats are 1. integrated directly into Base instead of an external package and 2. extremely well known and a global standard, I vote 👎

GMP is well know but not used for this (?), only MPFR, still well known. Also ArbLib, at least that underlying C library, if not ArbNumerics.jl?

I admit, I have an ulterior motive, I want BigFloat/MPFR gone, for now just suggesting an alternative. If more (know about) and use it, then it will be more practical later.

I don't think it belongs in base/numbers.md

I think it belongs in Julia's docs, and didn't find anywhere, and looked for a good spot. Do you have a better suggestion for a location?

[nsajko]

There are some benchmarks on mpfr.org, albeit it's quite possible they're outdated (I think they're from 2018): https://www.mpfr.org/mpfr-4.0.1/timings.html

[andrewjradcliffe]

Still is -0.0 very valuable?

Technically, it shouldn't be; the only case I can think of is one in which the sign of 0 is used to infer the direction from which the computation approached zero, but, given that this would be highly contextual, one would be better off working from the operands. It is quite likely that unless one has access to both the operands and operators that evaluated to -0.0, it would not be possible to determine how the -0.0 was produced.
On the other hand, there is likely some code in the wild which does blindly relies on -0.0. A contrived example is copysign.

[nsajko]

Division is presumably less contrived than copysign:

julia> pz = 0.0
0.0

julia> nz = -pz
-0.0

julia> 1/pz
Inf

julia> 1/nz
-Inf

There's a big difference between negative and positive infinity.

[PallHaraldsson]

Can someone who objected to documenting like I did make an edit suggestion with a language you would be ok with? I think at least something like ArbNumerics.jl is an alternative, with additional features, and in many cases faster. Which operation is faster? I think mul is important (and FMA?), and I see it was close from the benchmark. Other are faster, seemingly not all operations as I thought. But with its default smaller precision then well all operations should be way faster...

[brenhinkeller]

Cool!

[nsajko]

There's also Arblib.jl: https://juliahub.com/ui/Packages/General/Arblib

[KristofferC]

Linking to another library here is already a bit dubious but at least it is a pure Julia one.

[nsajko]

Both packages wrap the Arb C library: https://juliahub.com/ui/Packages/General/Arb_jll

[KristofferC]

Okay, then I don't think we need to do this at all.