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

**URL:** <https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292>\
**Category:** Numerics\
**Created:** [April 11, 2018, 10:47pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292 "2018-04-11T22:47:34Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kolaru](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kolaru/32/4574_2.png) [@Kolaru](https://discourse.julialang.org/u/Kolaru)\
**Post date:** [April 11, 2018, 10:47pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/1 "2018-04-11T22:47:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [April 11, 2018, 10:58pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/2 "2018-04-11T22:58:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Kolaru](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kolaru/32/4574_2.png) [@Kolaru](https://discourse.julialang.org/u/Kolaru)\
**Post date:** [April 12, 2018, 9:26pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/3 "2018-04-12T21:26:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![rdeits](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rdeits/32/286_2.png) [@rdeits](https://discourse.julialang.org/u/rdeits)\
**Post date:** [April 12, 2018, 9:36pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/4 "2018-04-12T21:36:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![dpsanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dpsanders/32/3573_2.png) [@dpsanders](https://discourse.julialang.org/u/dpsanders)\
**Post date:** [April 24, 2018, 11:29pm UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/5 "2018-04-24T23:29:44Z")

</div>

Yes exactly, it was overspecific typing in IntervalArithmetic.jl [here](https://github.com/JuliaIntervals/IntervalArithmetic.jl/blob/0897d41e0fdec7e77db380b481d8157eb184f358/src/display.jl#L190).

---

<div class="post-metadata">

**Author:** ![Kolaru](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kolaru/32/4574_2.png) [@Kolaru](https://discourse.julialang.org/u/Kolaru)\
**Post date:** [April 27, 2018, 12:00am UTC](https://discourse.julialang.org/t/precision-of-a-bigfloat-number-returning-an-int32-on-windows-10/10292/6 "2018-04-27T00:00:55Z")

</div>

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](https://github.com/JuliaIntervals/IntervalArithmetic.jl/issues/140).

Thanks for the answers.