Moving BigFloat to stdlib?

Internals & Design
1

With all the other things moving out of Base, there are not really many places where BigFloat is used anymore:

In int.jl, there is a parsing routine that would simply move to stdlib/BigFloat.jl
mpfr.jl would move to stdlib/BigFloat.jl
In printf.jl (which I’d thought had already moved to stdlib/Printf.jl), there is some code to print out BigFloats and BigInts.
There’s a single function in hashing2.jl, which also would just move to stdlib/BigFloat.jl.
There are a few lines in sysimg.jl:

include("mpfr.jl")
using .MPFR
big(n::Integer) = convert(BigInt,n)
big(x::AbstractFloat) = convert(BigFloat,x)
big(q::Rational) = big(numerator(q))//big(denominator(q))

There’s a line in exports.jl.

The only real use is in irrationals.jl, and I believe the BigFloat part of irrationals could be moved also out.

This would remove a large dependency from Base (the MPFR library),
and allow BigFloats to be updated without waiting on the Julia timeline.

2

Maybe i don’t have the full picture, but it looked like stdlib is still a dependency (i.e. you don’t run julia without stdlib)?

3

I’d thought the whole point of moving things to stdlib was so that you could run julia without the parts you didn’t want, such as LinAlg, etc.

1 Like
4

Yeah, it’s still a dependency of Julia proper, but IIUC it’s adding to the Base installation through the system image. So you then download Julia and build a version without them just by deleting a few things from the sysimg.jl

and since it’s disconnected from Base proper it won’t break anything. I am not sure whether it would still build MPFR, or the legal issues with the licensing at that point.

But anyways I think that BigFloat could go all the way to a package and >90% of people’s codes wouldn’t change, which would fix the issue entirely but could only be done in a 1.x if it’s in the stdlib instead of Base.

3 Likes
5

Unfortunately, we need big ints and big floats in the array hashing code to compute the difference between two subsequent elements in an array without any overflow or precision loss. That’s not great, but so far we haven’t found any other solution (see this PR). This system could be easily disabled via a build option, and hashing of ranges would then be O(N) instead of O(1), but by default I’m afraid we’ll have to keep the types in Base. Though we can avoid exporting them from Base and use a stdlib module for that instead.

2 Likes
6

Where are they being used in the array hashing code? I’d looked for all methods using BigFloat, but must have missed some places then where they are being used.

That’s my big issue, if they can be moved to stdlib, can’t they then be updated independently of Julia itself?

7

It’s used for widen. But the method doesn’t take BigFloat arguments, it returns BigFloat.

I’m afraid that if the type is defined in Base, it’s going to be quite complex to update the stdlib module independently. I guess some interfaces could be updated, but it would have to remain compatible with what lives in Base.

8

Opened https://github.com/JuliaLang/julia/issues/25716

3 Likes
9

9 posts were split to a new topic: Array hashing is complicated