# Discussion about integer overflow

**URL:** <https://discourse.julialang.org/t/discussion-about-integer-overflow/69627>\
**Category:** Internals & Design\
**Tags:** numbers, integer-overflow\
**Created:** [October 11, 2021, 12:44pm UTC](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627 "2021-10-11T12:44:33Z")\
**Posts on this page:** 1\
**Showing post:** 175

<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:** [October 15, 2021, 2:24pm UTC](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627/175 "2021-10-15T14:24:07Z")

</div>

> [@dlakelan](#):
>
> do all their math using decimal floats stored in strings

To be clear, [decimal floats](https://en.wikipedia.org/wiki/Decimal_floating_point) do _not_ need to be stored in strings. There is an IEEE decimal-floating point format using fixed-width binary-coded decimal, available in Julia via the [DecFP.jl package](https://github.com/JuliaMath/DecFP.jl). It is implemented only in software on the hardware supported by Julia, so it is slower than binary floating-point, but it’s still useful e.g. in financial applications where exact representation of human decimal inputs is required.

> [@dlakelan](#):
>
> Suddenly if 2^11 means a floating point number, and so does 3\*7 and 9+5, that’s not quite so true anymore, because you have to fight with the tool to get integer arithmetic.

Note also that, contrary to the popular superstition that `1.0 + 1.0 == 2.0 ± ε`, ordinary binary floats ala `Float64` are perfectly exact for working with _integers_ up to `2^53 == maxintfloat(Float64)`. `3.0 * 7.0` and `9.0 + 5.0` _are_ doing exact integer arithmetic, which happens to be stored as `Float64`.

That being said, I don’t think we seriously want to make all integers default to floating-point storage (ala Javascript, Matlab, or R). Putting aside questions of range of exactness (53 vs 64 bits), computer hardware is optimized to perform indexing operations (e.g. memory access) using integers, and using floats everywhere would lead to a massive slowdown. People only don’t care about this in languages where loops are slow anyway.

> [@ScottPJones](#):
>
> There is one issue that would need to be addressed to achieve that - currently the parser is lossy - in that it converts floating point literals immediately into Float64, instead of leaving the original form available so it could be picked up by a macro, and say, converted to BigFloat, or Dec64 / Dec128, without any digits being lost before the macro sees the literal.

Parsing decimal strings to `Float64` and converting back to strings is actually lossless in Julia — as long as your decimal has \< 14 digits, which should be true for any decimal that is worth representing exactly — because the float-printing algorithm ([Ryu](https://github.com/ulfjack/ryu), formerly Grisu) prints the _shortest_ decimal that rounds to the same binary-float value. See [this discussion](https://discourse.julialang.org/t/sum-of-float64-vector-gives-slightly-incorrect-answer/8577/20).

---

_[View the full topic](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627)._