Explain BigInt Like I'm Five

Floating Point Numbers

So, computers can represent numbers in a variety of ways. Anything works, as long as the computer knows how to do the things it needs to do to the numbers, like add them together, or print them out.

JavaScript normally represents all numbers as "floating-point numbers". This means that it stores a value between -2 and +2 (the mantissa), and then a number that it uses as a power of two to multiply that by (the exponent).

The useful thing about this is that it can represent a big range of numbers, but the accuracy it can store them at depends on how big the numbers are.

If you keep adding 1 to a number and you're using this type of representation, eventually you'll find that the 1 you're adding is too small to make a difference to the representation value!

This has caused bugs in the past, because the underlying system JavaScript is running on has another type of number that it uses for some important things: integers. These can't represent as big a range as floating-point numbers using the same number of memory bits, but always have the same level of accuracy: 1. If you add 1 to an integer it will go up by 1, and you can't add a fraction to it.

One notable example was when node.js had some problems because the integer labels for files stored on disk were too big to store accurately with floating-point numbers, so node.js was accessing the wrong files...

Overflows

When you want to store a number on a computer, you reserve a number of memory bits. You can only store a number of a certain size in that number of bits, and if you try to go over, you either get an exception, where the computer notices and tries to stop what you're doing, or you get a special-cased value, where the computer notices and puts a special type of value in the memory, or the numbers wrap around, losing some information, and getting an incorrect value.

These can each cause their own class of problems, but in any case, you don't want them to happen.

BigInt

To let you use accurate, whole numbers as large as you want, you need a special adjustable type of representation: one where if you need to store a larger number, a hidden layer asks for more memory to store it in, then keeps track of how many bits of memory and how many digits your large number has.

So, for example, if I want to store the number 384.

As a floating-point number, JavaScript's normal type, we store:


{ 1.5 times 2 to the power of 8 }


As a normal integer, we would store:

{ binary number: 110000000 }


As a (decimal version of a) BigInt, we could store:

{ 2 chunks of digits, they are: 3, and 84}.


But because they'd be binary numbers, it would work out as:

{ 2 chunks of digits, they are binary numbers: 1, and 10000000 }

(384 is 256 + 128).

So then, you also have to have a library of special ways to do arithmetic that know about how you've written these numbers.

If I want to multiply 12 by 16, I have to do something like:


{1 chunk of digits, it is: 12} * {1 chunk of digits, it is: 16}


I will need at least one chunk to store the result, so let's request that.

I know how to multiply two one-chunk numbers, that is: 192

This number is too big to fit in one chunk: I need an extra chunk to store the result, so request an extra chunk of memory.


Result is {2 chunks of digits, they are: 1, and 92}.


Result

This is a bit slower than using normal maths, but lets you handle numbers of any size: you can just keep requesting more chunks of memory to store them in. You still can't handle fractions, but you can pretend that all your numbers are only worth 100th of what they say they are, to get around that problem. (Fixed-point arithmetic.)

The BigInt library adds on a way to write these multi-chunk numbers, and a library of ways to work on them.

After a bit of searching, I found a pretty good explanation

Large integer IDs and high-accuracy timestamps cannot safely be represented as Numbers in JavaScript. This often leads to real-world bugs, and causes JavaScript developers to represent them as strings instead. With BigInt, this data can now be represented as numeric values.

For an ELI5 version, numbers in javascript are like a sandbox. If you pour in too much sand, it overflows the sandbox. If everyone in the world wanted to trade pokemon at the same time, it would be hard for the computer to keep track of which pokemon should go to the right person. It would be keeping tracking of billions of trades occurring all at once. With better time stamps and higher number counts, you can successfully trade billions of pokemon.

You are using a standard cart to transport your toys around the yard.
But once you get bigger you gain more and more toys.
Soon you realize (or it already happened) that the cart is full and the new toys will fall off.
You do not want to lose your precious toys so you build your own cart, which is a composed of multiple smaller carts (you can see it like a train of carts).
This way you can keep adding toys.

Cart - 1 integer
Toys - numeric values
Train of carts - big int

Javascript remembers numbers in a clever way (called 'double-precision floating point') that allows programmers to use really big numbers, really small numbers, numbers that have decimal points in them and numbers that don't all the same way, and mix them together without worrying which is which.

The problem is that there just isn't enough room for Javascript to store every possible number this way. There are lots of numbers Javascript just doesn't know about, and when you tell it to try, it just goes with whatever is the closest number it does know.

For most numbers this is OK, but for numbers you don't use very often (like really big ones), it can cause problems. For example, Javascript thinks that "9,007,199,254,740,992 + 1" still equals 9,007,199,254,740,992

This might seem like a REALLY BIG NUMBER that you're never going to use (and I'm sure the original Javascript engineers thought so too), but it turns out that programmers use really big numbers all the time, and changing them to a different number without the programmer knowing can cause all sorts of things to go wrong.

BigInt is a way to tell Javascript that you want to make sure your really big (or really small) numbers are remembered properly. You can't use decimal points any more, but at least your sums add up.

Microchips are made of transistors and they have 2 states

1. ON(1)
2. OFF(0)

Anything that runs in a computer turns into 0 or 1 so that the computer knows what to do.

For example '2' is represented as 0010 and 00000010 etc

Both the above mentioned numbers represent 2 in binary form but the digits it take to represent is different.

The first one is 4 bit representation and 2nd one is 8 bit.

So what happens when all the 8 bits are full and you want add another number with it

11111111(255) + 00000001(1)

When this operation happens there are three possibilities for an output . Either the excess bit will be cutoff or the computer recognises this operation and add another eight bits to it and the third one might be weird . It'll reset the count and start from its minimum value

Nowadays most computers are intelligent but it's a must known concept to understand Bigint

So what will happen if a number reaches a ** default maximum value of a computer ?? **

It happened to YouTube too

That's where user defined data types comes to scope .

It basically tells the computer to split a big value into small chunks and store in a separate variables and specifies how to do mathematical operations.

Bigint is one such data type .

[Here's a link which gives a decent comparison ](sqlhints.com/2017/06/04/difference...

For what it worth, I just wrote an article about BigInt. Not really "explain like I'm five", but you sure can learn a few things.

Arbitrary large integer

Guillaume Martigny ・ Aug 2 ・ 2 min read

#javascript #tutorial