Move `BigFloat` to stdlib

[simonbyrne]

BigFloat could be moved to a stdlib package (BigFloats? MPFR?), though there are a few places it is coupled to Base:

• widen(::Float64) and big(::AbstractFloat)
  • Should we just leave these undefined, and type-pirate them in the package?
• array hashing (which calls widen)
  • Should be doable via TwicePrecision tricks I misunderstood what the widen was for.
• @irrational macro, which defines a BigFloat method
• Float64(::Irrational,::RoundingMode) (which is used in floating point inequalities)
• Rational{T}(::Irrational) and rationalize(::T,::Irrational)

c.f. https://discourse.julialang.org/t/moving-bigfloat-to-stdlib/8545

[ViralBShah]

We should definitely move BigFloat to stdlib.

[simonbyrne]

One possible solution to the Irrational ones is that we manually define the necessary methods for the built-in ones (pi, e, etc.), and then move the @irrational macro itself to the new package?

[JeffBezanson]

Yes, that sounds ok. The type piracy here also does not bother me. Initially you have no way to widen a Float64, but if you load the BigFloats package then you do. Makes sense to me.

[nalimilan]

As I noted on Discourse, I'm afraid we can't define widen(::Float64) in the stdlib, or you wouldn't be able to hash heterogeneous arrays containing Float64 values without loading the BigFloats stdlib module. The reasons for this are complex, and so far we haven't found any alternative (#16401). However, we could move all user-facing APIs to the stdlib and only use BigFloat internally.

[StefanKarpinski]

I don't see a ton of advantage to this. We basically need to have BigInt in Base since we have syntax for it (long integer literals). We only export BigFloat itself and setprecision from the MPFR module, so it's not like it's a big contributor to Base API bloat. We already have the big function which we would like to have continue to work on floats without needing to load BigFloats so we need to have the BigFloat functionality loaded in the system image no matter what. So it seems like the only real change would be that if people want to change the default BigFloat precision they would have to write using BigFloats before doing setprecision. However, the setprecision function seems to aim to be generic – although it also only seems to currently support changing the precision of BigFloat and I'm not sure what else it could even change the precision of.

[pkofod]

nd I'm not sure what else it could even change the precision of.

other arbitrary precision numbers? (I mean, packages might extend the function with a method for arbfloats, ...)

[StefanKarpinski]

Right, so we want a shared extension point anyway, which means to me that setprecision doesn't even really belong to BigFloats – it just happens to be defined there because BigFloat is the only Base type that it applies to. So really the only thing that would be exported from a BigFloats standard library would be the BigFloat type itself.

[simonbyrne]

The main advantage as I see it is that the MPFR dependency could eventually be made optional.

[JeffBezanson]

Agreed, I see this as a step towards making MPFR fully optional.

[ViralBShah]

Is this still something we can accomplish? Assuming the list that @simonbyrne posted is roughly accurate, it seems quite doable.