# Should large exponentials not yield Inf?
**URL:** https://discourse.julialang.org/t/should-large-exponentials-not-yield-inf/81143
**Category:** General Usage
**Tags:** question, numerics, integer-overflow
**Created:** [May 16, 2022, 10:19am UTC](https://discourse.julialang.org/t/should-large-exponentials-not-yield-inf/81143 "2022-05-16T10:19:51Z")
**Posts on this page:** 1
**Showing post:** 6
### Author:  [@Palli](https://discourse.julialang.org/u/Palli)
#### Post date: [May 16, 2022, 11:38am UTC](https://discourse.julialang.org/t/should-large-exponentials-not-yield-inf/81143/6 "2022-05-16T11:38:20Z")
> [@nil](#):
>
> ```julia
> julia> 456^789
> 0
>
> ```
>
> This results in wrong values inside functions
This is right(!) in some technical (modular) sense. Modular arithmetic is the default for machine integers, and they can’t be `Inf`. So `Int`^`Int`, CAN’T result in `Inf`, if, given that it results in `Int`. I would argue it _should_ result in `Float64`, similar to division, for the same reasons (at least for signed integers), when the power is (possibly) negative. Right now, power returns `Int` for purity reasons, that arguably do not apply to it, only the other operators.
> [@Sukera](#):
>
> Julia integers are machine integers, `^` on integers does integer exponentiation. Checking for overflow & throwing an error/giving a warning would prevent a lot of optimizations like vectorization to take place.
I’m not sure a lot of code relies on integer exponentiation, but it it does then plan b could be to check for overflow and throw an error, and I’m not sure it will be slow or prevent optimization. Because I think there’s no such assembly instruction.
> [@Discussion about integer overflow](https://discourse.julialang.org/t/discussion-about-integer-overflow/69627/104):
>
> Because of overflows, and getting rid of them with this idea would be a great option: Doesn’t need to be.\* That was about changing the default, but the default type for integers doesn’t need to change, only the non-default option, so we do not have to wait for Julia 2.0 (only if we change the default later, what I’m not proposing now). The question is what should replace the default integers, and I’m a bit conflicted, BigInt or SaferIntegers.jl. The argument for the former is that it’s al…
>
>
> This seems sensible, and consistent with division (which is implied when b is ne…gative). There needs to be an exception when a or b is a BigInt (or then return BigFloat, while BigInt result needs to also be an option). I'm not sure this would break a lot of code, but a way to get old behavior is I guess needed (and already existing).
>
> If this is too breaking just add the 2.0 milestone...
>
> Plan B would be overflow check (I'm not sure there's a separate open issue on it). It's a less good option IMHO, while it wouldn't be breaking, and would also apply for unsigned.
---
_[View the full topic](https://discourse.julialang.org/t/should-large-exponentials-not-yield-inf/81143)._