`precision` of a `BigFloat` number returning an `Int32` on Windows 10

Specific Domains Numerics
1

I recently encountered a strange comportment on my machine :

julia> typeof(precision(2.2))
Int64
julia> typeof(precision(BigFloat(2.2)))
Int32

I tried the same code in JuliaBox and there it returns an Int64 both time, so I assume it is the expected behavior.

After some researches I found that the problem is porbably in the call to the libmpfr library in the precision definition :

function precision(x::BigFloat)  # precision of an object of type BigFloat
    return ccall((:mpfr_get_prec, :libmpfr), Clong, (Ptr{BigFloat},), &x)
end

However reinstalling Julia did not solve the problem. Anyone has an idea on how to solve the problem (except by adding an explicit conversion in the source file) ? Or should I open an issue about it ?

I run Julia v0.6.2 (installed from the x86_64-w64-mingw32 binary) on a Windows 10.

2

Is this a problem? Your version of MPFR simply uses a 32-bit integer (a C long) to represent the precision value, while Julia itself uses a machine Int (Int64) to represent the precision of its own Float types. Unless you need more than 2147483647 bits of precision, then it shouldn’t cause issues. The fact that precision can return different types for different input types is perfectly normal in Julia.

1 Like
3

First of all thank you for your reply.

At first it looks like a mere discomfort, I must admit, as the result can be converted to the correct Int type when needed. But the discomfort is a bit bigger than what it looks like at first glance, since it makes fail some functionalities of the IntervalArithemtic package that specifically expecta Int (which translates to Int64 in my case) for some of its functions (essentially for display).

My question actually makes a bit more sense in the context of contribution : if the return type of the precision is expected to vary from one installation to the other, the fix shall be made in the IntervalArithmetic package and I can easily make a pull request for it. On the other hand if it is unexpected, the issue is with base and fixing it in a meaningful way may be beyond my current understanding of the problem.

Finally, if it is about the version of MPFR, I realize that it may as well explain why on my machine the test suite of the IntervalArithmetic package fail on some other points as well (on my machine), and I am a bit worried that some other functionalities may not work as expect.

4

It’s very hard to answer without a concrete example. What is the problem you’re seeing?

But in general, this sounds like IntervalArithmetic is just being too picky about the type it’s expecting. And if its unit tests are failing for you, then opening an issue on that package seems perfectly reasonable.

2 Likes
5

Yes exactly, it was overspecific typing in IntervalArithmetic.jl here.

6

Oh sorry guys, I somehow forgot about this thread (was busy installing a Linux distribution to avoid the issue, which worked perfectly).

The IntervalRootFinding package is now fine on my Windows, but the tests of the IntervalArithmetic package fail. I have opened a corresponding issue here.

Thanks for the answers.