# Why can I just write BigInt("12345")

Just on the heels of finding three cubed numbers that [sum to 42], scientists have passed another important milestone by finding three enormous cubes that sum to 3.

``````julia> parse(BigInt,"569936821221962380720")^3 + parse(BigInt,"-569936821113563493509")^3 + parse(BigInt,"-472715493453327032")^3
3
``````

But why is it so difficult to verify using julia.

Why can’t I just write

``````julia> bigint("569936821221962380720")^3 + bigint("-569936821113563493509")^3 + bigint("-472715493453327032")^3
ERROR: UndefVarError: bigint not defined
Stacktrace:
[1] top-level scope at REPL[11]:1

julia> BigInt("569936821221962380720")^3 + BigInt("-569936821113563493509")^3 + BigInt("-472715493453327032")^3
ERROR: MethodError: no method matching BigInt(::String)
Closest candidates are:
BigInt() at gmp.jl:56
BigInt(::BigInt) at gmp.jl:254
BigInt(::Union{Int32, Int64}) at gmp.jl:285
...
Stacktrace:
[1] top-level scope at REPL[12]:1

``````
``````julia> big"569936821221962380720"^3 + big"-569936821113563493509"^3 + big"-472715493453327032"^3
3
``````

Edit: As said below, just using a number to `big` is in this case probably better since you are not doing any computations on the number before turning it into a `BigInt` and Julia will automatically chose a number type that is big enough for numeric literals.

2 Likes
``````julia> big(569936821221962380720)^3 + big(-569936821113563493509)^3 + big(-472715493453327032)^3
3
``````

There’s no `bigint` function. Simple as that. Just use `big`.

``````julia> BigInt(569936821221962380720)^3 + BigInt(-569936821113563493509)^3 + BigInt(-472715493453327032)^3
3
``````

Perhaps `big"..."` could be mentioned in https://docs.julialang.org/en/v1.4-dev/manual/integers-and-floating-point-numbers/#Arbitrary-Precision-Arithmetic-1 .

I will make a PR.

1 Like

How come I dont need to enclose it with a string. Why does it not turn to Int64 before being process by the function BigInt()

How come I dont need to enclose it with a string. Why does it not turn to Int64 before being process by the function big()

Because the input is a number literal. The compiler sees that it’s too big for `Int64`. It’s actually a `Int128` before the `BigInt` construction:

``````julia> typeof(569936821221962380720)

Int128
``````
1 Like
``````julia> typeof(1234567890123456789012345678901234567890)
BigInt

julia> 1234567890123456789012345678901234567890^3
1881676372353657772546716040595286755373973700255343476997709998147026668834432100633207693797722198701224860897069000
``````

hmmm seems like I only need to use big(12345) if the number is NOT big enough!

This is counter-intuitive

Well, by default all integers are `Int` (if it fits). If you want something else you need to use `UInt8(myint)` or `big(myint)` etc.

You need to convert by using `big` if you know the result is going to overflow otherwise:

``````julia> typemax(Int)^3
9223372036854775807

julia> big(typemax(Int))^3
784637716923335095224261902710254454442933591094742482943
``````

Why? It’s just like that 1.0 is automatically a Float64, while 1 is automatically Int. You only need to specify what you want if it is not automatically obvious.

Would that be a good place to also mention/refer to `big()`?

It’s just a kind of literal. `0x234` gets parsed as `UInt16`. Long sequences of digits get parsed as `Int128` or `BigInt`, depending on length.

What do you think the compiler should do with something like `1234567890123456789012345678901234567890`?

If you don’t like using `big()`, then you have to implement some kind of overflow checking which is not trivial and most high performance languages don’t do. I only know about `checked` keyword in C#, a similar functionality can be achieved with a package, but forcing this behavior language-wide is a big performance killer and source of more bugs. `big` is not worse than `checked` I guess.