Are BigFloat (and BigInt) simply inferior?

[PallHaraldsson]

to this package (or ArbFloat or ArbReal)?

[JeffreySarnoff]

BigInt does not apply -- ArbNumerics are all about very precise [complex or real] floating point values and floating point intervals that are assured to enclose the true mathematical result. ArbNumerics benchmarks considerably faster than BigFloat for most uses at computational precisions as high as 6,000 bits. BigFloats are entirely portable and always available within the Julia ecosystem -- which is useful. ArbNumerics supports many more advanced mathematical functions than does BigFloat.

[PallHaraldsson]

Thanks, I think you (and your docs on the C library) are basically confirming the package superior; or ArFloat to BigFloat.

BigFloats are entirely portable and always available within the Julia ecosystem

Right, and that seems like a plus for users, but just since it's available without relying on a package. I think it defaults to 256 bits so ArbFloat wouldn't be a drop-in-replacement.

I was thinking, with asking: BigFloat isn't relevant to most Julia users and should simply be dropped, to e.g. reduce the sysimage.

You could do then:

const BigFloat = ArbFloat

I see:

Initially, the default precision is set to 106 bits excpeted [typo]

There's likely a reason/story behind it. Seemingly just a good next step, 2x Float64, i.e. double-double.

That would be a breaking change if not adding your a a drop-in replacement... (if simply dropped, or if kept and with same API but lower precision, would most users care?), but most people seemingly should be using your library anyway, so it could be handled two ways.

1. Simply documenting it, and force users to add your package (or an excised BigFloat.jl). I guess implies 2.0, but good trade-off to me.
2. Add your package as a stdlib. Either way it would add to your userbase... but unclear you would want it as a stdlib or the attention. Since your package seems larger, conflicting with at least my goal... I see it uses MPFR, but also GMP for some reason I don't see. Maybe since you support intervals, and I'm not sure we want to add that to Julia. I mean hypothetically, and would be useful to many users, just not needed minimal 1.x replacement.
3. Status quo is a 3rd option, at least your package should be documented, in Julia docs, if it isn't already... It seems users could still do:

const BigFloat = ArbFloat

It probably wouldn't do much except lower precision... I'm undecided if new BigFloat should keep it old precision as a default, and ArbFloat could still exist with its (probably not though with that simple const). Julia promises a stable API, and I think we could argue we never promised 256 bits, just document:

setprecision(256)

Can you think of a reason why your package couldn't be a (faster) drop-in-replacement? What did you mean by "entirely portable"? If your package were built-in it would be available on all platforms Julia supports?! [I mean I think your package supports same.] Do you mean if you call e.g. some C code that expects MPFR format? Since you use its MPFR JLL could you still do that? Is it just for converting to and from BigFloat? I think it's an even less used feature for most users, could be simply dropped, and added in a package for those who need?

[I would like to get rid of BigInt to, could be a separate phase, so then I'm curious of your use of GMP, which wouldn't be bad for now, but possibly later for its excision. Do you know is there any real alternative to it? None faster or more featureful, but possibly slower and smaller? Just a question of having it or not (for 2.0) then.]

I would also want to get rid of Julia's Rational type. Not because it takes too much space in the sysimage, but rather it's useless for most, orerflows possibly be defautl for those that need it, and rationals of BigInts slow. I have my own idea for a new Rational that would only take 64-bits or less, then (if installed) promote to of BigInts if needed. I'm not sure if it makes sense, but possibly to ArbFloat or ArbReal.