# Different results between 10^50 and 10.0^50

**URL:** <https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401>\
**Category:** New to Julia\
**Created:** [April 25, 2025, 1:16pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401 "2025-04-25T13:16:27Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![quantum2025](https://avatars.discourse-cdn.com/v4/letter/q/90ced4/32.png) [@quantum2025](https://discourse.julialang.org/u/quantum2025)\
**Post date:** [April 25, 2025, 1:16pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/1 "2025-04-25T13:16:27Z")

</div>

I am studying the Julia language, and found a strange result, that is 10^50 and 10.0^50 generate opposite results:

```julia
julia> 10.0^200
1.0e200

julia> 10.0^200000
Inf

```

Can anyone tell the reason behind this result? Is it due to some internal design of Julia in processing overflowed numbers? Thanks.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [April 25, 2025, 1:26pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/2 "2025-04-25T13:26:16Z")

</div>

> **[Frequently Asked Questions · The Julia Language](https://docs.julialang.org/en/v1/manual/faq/#faq-integer-arithmetic)**
>
> Documentation for The Julia Language.

---

<div class="post-metadata">

**Author:** ![John\_Gibson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/john_gibson/32/5321_2.png) [@John\_Gibson](https://discourse.julialang.org/u/John_Gibson)\
**Post date:** [April 25, 2025, 1:32pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/3 "2025-04-25T13:32:10Z")

</div>

The maximum finite 64-bit floating point number is about 10^308.

```julia
julia> typemax(Float64)
Inf

julia> prevfloat(typemax(Float64))
1.7976931348623157e308

```

This is not an issue with Julia. It’s a property of IEEE 64-bit floating-point numbers. The same thing happens in any language that uses standard floating-point numbers.

---

<div class="post-metadata">

**Author:** ![quantum2025](https://avatars.discourse-cdn.com/v4/letter/q/90ced4/32.png) [@quantum2025](https://discourse.julialang.org/u/quantum2025)\
**Post date:** [April 25, 2025, 1:44pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/4 "2025-04-25T13:44:21Z")

</div>

Thanks. I understand that an overflowed float number like 10.0^50 is represented by Inf, which is reasonable. But I was wondering why an overflowed integer 10^50 is represented by 0. Why isn’t it also Inf? I am a little curious.

---

<div class="post-metadata">

**Author:** ![quantum2025](https://avatars.discourse-cdn.com/v4/letter/q/90ced4/32.png) [@quantum2025](https://discourse.julialang.org/u/quantum2025)\
**Post date:** [April 25, 2025, 1:47pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/5 "2025-04-25T13:47:17Z")

</div>

Thanks. I understand that Julia does not track the overflow of big numbers due to the efficiency considerations. But I was just wondering why overflowed integer and overflowed float number give different results? Shouldn’t both be Inf?

---

<div class="post-metadata">

**Author:** ![gmcardle](https://avatars.discourse-cdn.com/v4/letter/g/34f0e0/32.png) [@gmcardle](https://discourse.julialang.org/u/gmcardle)\
**Post date:** [April 25, 2025, 2:00pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/6 "2025-04-25T14:00:06Z")

</div>

typeof(Inf) is Float64. Or to put it another way, the IEEE floating point data type defines bitstrings that represent concepts like Infinity and NaN, whereas the Int data type can only contain an integer and has no way to represent Infinity

---

<div class="post-metadata">

**Author:** ![John\_Gibson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/john_gibson/32/5321_2.png) [@John\_Gibson](https://discourse.julialang.org/u/John_Gibson)\
**Post date:** [April 25, 2025, 2:02pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/7 "2025-04-25T14:02:42Z")

</div>

No, real numbers and integers are very different number systems, and the computer approximations of these numbers systems are different and behave differently. Floating-point numbers have Infs and NaNs; computer integers do not.

```julia
julia> 10^50
-5376172055173529600

```

64-bit IEEE computer integers actually implement \mathbb{Z}/n, the integers mod n, for n=2^{64}. This number system is closed under arithmetic operations. The above calculation is correct for \mathbb{Z}/n, n=2^{64}.

One might devise a finite computer integer type that behaved like your expectations. But it would not be as mathematically rational as the integers mod n. I’m not a hardware person but I suspect a finite integer system that produced infs on overflow would necessarily be less efficient than one that straightforwardly implements \mathbb{Z}/n.

---

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [April 25, 2025, 2:35pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/8 "2025-04-25T14:35:47Z")

</div>

> [@John\_Gibson](#):
>
> m not a hardware person but I suspect a finite integer system that produced infs on overflow would necessarily be less efficient than one that straightforwardly implements \mathbb{Z}/n.

On our real existing PC hardware, the circuitry for wrapping integer arithmetic is present and paid-for and is optimized to death, while circuitry for saturating integer arithmetic didn’t make the cut.

That being said, saturating integer arithmetic is not too exotic, afaiu plenty of micro-controllers and special purpose hardware have circuitry for that. Heck, lot’s of CPU internals use saturating integer arithmetic (eg branch history tables).

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 25, 2025, 6:20pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/9 "2025-04-25T18:20:03Z")

</div>

> [@foobar\_lv2](#):
>
> On our real existing PC hardware, the circuitry for wrapping integer arithmetic is present and paid-for and is optimized to death

I didn’t realize any particular wrapping behavior was needed, I thought it just came as a result of how any integer arithmetic operation worked. Is overflow not intrinsically a more complex operation?

---

<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:** [April 25, 2025, 7:29pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/10 "2025-04-25T19:29:41Z")

</div>

> [@quantum2025](#):
>
> I understand that an overflowed float number like 10.0^50 is represented by Inf, which is reasonable. But I was wondering why an overflowed integer 10^50 is represented by 0. Why isn’t it also Inf?

Floating point types, including Julia’s, generally follow (or very closely) the IEEE-754 standard, which is designed to set some bit patterns to `Inf` among other things. Integer types generally do not; every bit pattern is an integer value, and an operation going beyond the type’s range results in underflow or overflow to the wrong values.

> [@quantum2025](#):
>
> 10^50 is represented by 0

Not always. First, you should be informed that integer literals (a single value you type) can be parsed as different types depending on how big they are. On my system, the smaller ones are 64-bit, at some point it parses as 128-bit for the larger range, and at extremes it parses as arbitrary-precision integers:

```julia
julia> 0 |> typeof
Int64

julia> 1234567898765432123 |> typeof
Int64

julia> 12345678987654321234 |> typeof
Int128

julia> 123456789876543212345678909876543212345 |> typeof
Int128

julia> 1234567898765432123456789098765432123456 |> typeof
BigInt

```

You’re using small inputs, so I would expect `Int64` inputs and outputs on my system, which I get:

```julia
julia> 10^50 |> typeof
Int64

julia> 10^50
-5376172055173529600

```

Obviously some overflow occurred, but not to 0!. Which brings me to the other way integers can be parsed differently; on 32-bit systems, small integers are parsed to 32-bit integers, which do overflow to 0 for your case:

```julia
julia> Int32(10)^Int32(50)
0

```

On 32-bit systems, Julia will also parse to progressively larger-range integer types (64-bit, 128-bit, arbitrary precision) for larger integer literals. Literals with a decimal point will parse to 64-bit floating point regardless of the magnitude or system. Integers get the special treatment because of how the CPU processes data at once (a word) and their usage in memory addresses; Julia does this with the type aliases `Int`/`UInt` being assigned to `Int32`/`UInt32` or `Int64`/`UInt64` depending on the system

---

<div class="post-metadata">

**Author:** ![mcabbott](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mcabbott/32/6603_2.png) [@mcabbott](https://discourse.julialang.org/u/mcabbott)\
**Post date:** [April 25, 2025, 7:50pm UTC](https://discourse.julialang.org/t/different-results-between-10-50-and-10-0-50/128401/11 "2025-04-25T19:50:43Z")

</div>

There are various packages with checked / saturating integers, for example

```julia
julia> CheckedArithmetic.@check 10^18
1000000000000000000

julia> CheckedArithmetic.@check 10^19
ERROR: InexactError: trunc(Int64, 10000000000000000000)

```

and

```julia
julia> OverflowContexts.@saturating 10^18
1000000000000000000

julia> OverflowContexts.@saturating 10^19
9223372036854775807

julia> OverflowContexts.@saturating 10^20
9223372036854775807

```

but not

```julia
julia> FixedPointNumbers.Fixed{Int8,0}(10) ^ 2
100.0Q7f0

julia> ans + ans
-56.0Q7f0

julia> FixedPointNumbers.Fixed{Int8,0}(200)
ERROR: ArgumentError: Q7f0 is an 8-bit type representing 256 values from -128.0 to 127.0; cannot represent 200

```