Why can I just write BigInt("12345")

General Usage
1

According to Mathematicians No Longer Stumped By The Number 3

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
2 
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
3 
julia> big(569936821221962380720)^3 + big(-569936821113563493509)^3 + big(-472715493453327032)^3
3

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

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

Perhaps big"..." could be mentioned in Integers and Floating-Point Numbers · The Julia Language .

I will make a PR.

1 Like
6

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()

7

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()

8

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
9 
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

10

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
11

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.

12

https://github.com/JuliaLang/julia/pull/33322

13

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

14

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?

15

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.