# Should InexactError be thrown when converting from Int64 to Float64?

**URL:** <https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531>\
**Category:** General Usage\
**Tags:** exception, float, rounding\
**Created:** [January 8, 2025, 10:08am UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531 "2025-01-08T10:08:07Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![xor0110](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xor0110/32/7926_2.png) [@xor0110](https://discourse.julialang.org/u/xor0110)\
**Post date:** [January 8, 2025, 10:08am UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531/1 "2025-01-08T10:08:08Z")

</div>

Converting from Float64 to Int64 works fine if the number is an integer, otherwise a `InexactError` is thrown, and the user is required to use a function such as round or floor to perform the conversion in general.

```julia
julia> Int64(1.0)
1

julia> Int64(1.1)
ERROR: InexactError: Int64(1.1)
Stacktrace:
 [1] Int64(x::Float64)
   @ Base ./float.jl:994
 [2] top-level scope
   @ REPL[34]:1

```

The converse is not always exact, though:

```julia
julia> 2^53 == Float64(2^53)
true

julia> 2^53+1 == Float64(2^53+1)
false

```

There are Int64 numbers that cannot be represented with enough accuracy in Float64. In a way, it’s the same problem: one type can represent values with more accuracy than the other, accuracy is being lost in the conversion. Shouldn’t the same `InexactError` be throw in this case?

This has practical importance: if you represent dates or geographical coordinates you often have numbers varying around a large bias, and it may work fine as fixed-point integers, but converting to Float will lose precision.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [January 8, 2025, 10:50am UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531/2 "2025-01-08T10:50:44Z")

</div>

No because

- it’s breaking, we’re long past that
- we don’t have to throw an error when its documented condition is met. It could be handled another way, or we could opt out in exception handling.

Converting to a type with lower precision is accepted as silent or warned approximation in many languages. Conversions to lower precision floating point logically could’ve gone the way you’re proposing, but it’s already unusual to even throw `InexactError`s in this many situations.

---

<div class="post-metadata">

**Author:** ![mbauman](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mbauman/32/31082_2.png) [@mbauman](https://discourse.julialang.org/u/mbauman)\
**Post date:** [January 8, 2025, 7:27pm UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531/3 "2025-01-08T19:27:27Z")

</div>

It’s also worth noting that the `Float*` constructors all round in many other situations, too. For example:

```julia-repl
julia> Float64(2//3)
0.6666666666666666

julia> Float32(1.00000001)
1.0f0

```

In fact, the documentation says this is a rounding operation — and you can pass an optional `RoundingMode` argument to specify how it should happen.

```julia-repl
julia> Float64(2//3, RoundUp)
0.6666666666666667

julia> Float32(1.00000001, RoundUp)
1.0000001f0

```

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [January 8, 2025, 7:30pm UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531/4 "2025-01-08T19:30:24Z")

</div>

> [@xor0110](#):
>
> Shouldn’t the same `InexactError` be throw in this case?

This was discussed in [should convert(Float64, 2^53+1) be an InexactError? · Issue #12187 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/12187) back in 2015.

The basic argument here is that construction of floating-point values, whether from integers, or rationals like `1//3`, arithmetic expressions like `1/3`, or literal values like `0.1`, is commonly understood to involve rounding. Requiring the rounding to be explicit just in the constructor/`convert` context would therefore be unnecessarily awkward.

That’s not the case with types like `Int` or `Rational`, where operations are understood to be exact unless rounding is requested explicitly.

---

<div class="post-metadata">

**Author:** ![xor0110](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/xor0110/32/7926_2.png) [@xor0110](https://discourse.julialang.org/u/xor0110)\
**Post date:** [January 9, 2025, 7:13am UTC](https://discourse.julialang.org/t/should-inexacterror-be-thrown-when-converting-from-int64-to-float64/124531/5 "2025-01-09T07:13:57Z")

</div>

Thanks everyone for the insightful comments, I couldn’t find the previous discussion. I guess in the end rounding is part of life when your result is a float, and the fact you can exactly convert some floats to int is actually kind of a quirk.