2^big(64) is an Int

[my-little-repository]

Hi, I just tried the julia0.4rc. I see an unexpected behavior in some test. 2^big(64) is an Int, and thus underflows. I am pretty sure that this was a BigInt six month ago. Not sure if it is a bug though.

  julia> 2^big(64)
  0

[JeffBezanson]

Wow, yes, this worked in 0.3.

[nolta]

d9bcdeb

I'm sorry, i should have made a PR, but it seemed pretty unambiguous at the time.

[JeffBezanson]

Of course, the funny part is, not even GMP itself supports raising a BigInt to a BigInt power, since if your exponent is that large you're kind of in trouble.

[ivarne]

What should be done here? Just revert d9bcdeb, or are there other ways that might satisfy both @my-little-repository and @nolta?

[JeffBezanson]

I suppose on grounds that x^3 is x*x*x, the "3" is not really involved in the computation in some sense. So I'm not sure what's best here.

[staticfloat]

The problem with that line of reasoning is that in 2^1.5, the fact that 1.5 is a float definitely changes the output type; so we have precedent for "unusual" exponent types taking over the output type of the exponentiation. I get that at its heart, floating-point exponentiation is a different algorithm than integer exponentiation, but from a purely "operator-as-a-blackbox" standpoint, I wouldn't say one viewpoint is immediately correct over the other.

[my-little-repository]

In my use case, the exponent is the argument of a function, ultimately provided by the user. In case of an integer overflow, the user can just provide a BigInt as an argument and the whole computation will switch to arbitrary precision.

Sometimes we provide a BigInt as an input not because the input is a huge number, but because the computation leads to a huge output. Think about the factorial function. Or to some myexp2 function defined as myexp2(n) = 2^n.

Anyway, I am just pointing out an unexpected change in the 0.4 release candidate, I certainly can start writing two versions for each function that uses exponentiation, one for int, the other for bigint.

By the way, exp2 is in base and we have

julia> exp2(big(64))

1.844674407370955161600000000000000000000000000000000000000000000000000000000000e+19

I think that it would be more natural to return a BigInt here instead of a BigFloat. Or explicitely warn in the documentation that this function is not meant for integer typed computations.

[JeffBezanson]

Yes, on the whole I'd say we should switch back to the 0.3 behavior. People do expect bigints to "propagate".

[tkelman]

backported in #13107