MDN doc
BigIntis a built-in object that provides a way to represent whole numbers larger than 2^53 - 1, which is the largest number JavaScript can reliably represent with theNumberprimitive and represented by theNumber.MAX_SAFE_INTEGERconstant.BigIntcan be used for arbitrarily large integers.
Difference:
BigIntcannot be used with methods in the built-inMathobject and cannot be mixed with instances ofNumberin operations- Because coercing between
NumberandBigIntcan lead to loss of precision, it is recommended to only useBigIntwhen values greater than 2^53 are reasonably expected and not to coerce between the two types.
Videos
Hi there, I'm learning data types in javascript. Messing around. I used these variables.
let x = 15;
let y = 123456789999;
typeof shows them both as numbers. So it got me thinking...
Where does number end and bigint begin? I went as high as let y = 1234567899999999999999999999999999999; and it was still a number. When I put an n on the end, it's bigint, so
What does n stand for or translate to? Is it infinity, or does it make it some continuous number? I thought number and bigint were separate DTs for memory purposes, so
Is there an explicit way to declare a number vs bigint? I want to see what happens if I declare a bigint as a number and vice versa. But number is reserved, so I can't "let number = 123456789999n".
Lastly, does anyone use bigint in programming, I mean, does it serve a practical purpose?
Thanks
MDN doc
BigIntis a built-in object that provides a way to represent whole numbers larger than 2^53 - 1, which is the largest number JavaScript can reliably represent with theNumberprimitive and represented by theNumber.MAX_SAFE_INTEGERconstant.BigIntcan be used for arbitrarily large integers.
Difference:
BigIntcannot be used with methods in the built-inMathobject and cannot be mixed with instances ofNumberin operations- Because coercing between
NumberandBigIntcan lead to loss of precision, it is recommended to only useBigIntwhen values greater than 2^53 are reasonably expected and not to coerce between the two types.
The differences between BigInt and Number:
Number |
BigInt |
|
|---|---|---|
| Safe Range | Number.MAX_SAFE_INTEGER; loses precision outside of this range |
Extremely large integers |
| Math operations | Supports the Math object |
Basic arithmetic operations: + * - % ** |
| Decimal vs. Integer support | Integers and decimals, e.g 1.00, 2.56 |
Only integers, e.g 1n, 2n. 5n / 2 === 2n |
| Syntax | No special syntax | Append n to the end of a number literal or use new BigInt('100') |
| Type Conversion | Automatically converts Number to BigInt in operations |
Requires explicit conversion to Number for arithmetic involving Number values |
| JSON | Supported by default | Not serializable by default |
Use BigInt when you need to work with extremely large integers or require precise integer arithmetic without any loss of precision.
Those are not necessarily one recommendation. It can easily be two interrelated ones.
Only use
BigIntfor integers that reasonably may exceed 2^53.A
BigIntisn't a general-purpose number. It's specifically for large integers, hence the name. They're best when used in specific, isolated cases where you expect large integers may well appear, in no small part because in other cases, the design goals (including preventing accidental losses of precision) make the type too restrictive to be useful. You can't doMathstuff with them, you can't mix types, etc. For numbers you know will be less than 2^53, aNumberwill be far less restricted (read: more useful), and generally much faster and easier to work with.(For an example of the performance difference, see https://jsperf.com/bigint-vs-number/5. The test at first showed a 1% difference at first in Chrome, but once your values aren't effectively constant, it's harder to hide the differences, and performance drops drastically.)
Don't convert between
BigIntandNumber.The entire point of
BigIntis to serve as an arbitrary-precision integer. Converting to aNumbertakes all those extra bits you asked for, and shoehorns them into a double-precision float. Only the most significant 52+1 bits will be preserved. If you can tolerate that happening, you probably don't need aBigIntin the first place.
They're interrelated in that the temptation to convert gets greater the more you deal with BigInts that would be better off as Numbers and bump into the limitations of the type. The thing is, those limitations are for the most part quite intentional. You can better avoid those limitations by not using BigInt than by sidestepping them and throwing bits away.
As far as I understand it, there is no implicit type coercion, only explicit type cast.
Indeed.
Should I not use
BigInt, when my numbers are "small"? I see no good reason to avoid it.
I'm not a heavy user of BigInt but I agree with your remark: if you rely on integers in a range that is beyond Number.MAX_SAFE_INTEGER, you should definitely want to use BigInts, for large as well as "small" integers.
Actually I guess the disclaimer in the MDN documentation should be interpreted in the other way around: if you need large integers, try your best not to use type casts, namely, don't use Numbers in the first place.
This is by the way what suggests that other paragraph in the MDN documentation:
Be careful coercing values back and forth, however, as the precision of a
BigIntmay be lost when it is coerced to aNumber.