# GitHub - js-choi/proposal-bigint-math: Draft specification for supporting... **URL:** \ **Category:** 🦋 Proposals\ **Tags:** proposal\ **Created:** [August 22, 2021, 10:48am UTC](https://es.discourse.group/t/github-js-choi-proposal-bigint-math-draft-specification-for-supporting/942 "2021-08-22T10:48:34Z")\ **Posts on this page:** 1\ **Showing post:** 16
**Author:** ![Rudxain](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/rudxain/32/2272_2.png) [@Rudxain](https://es.discourse.group/u/Rudxain)\ **Post date:** [November 1, 2024, 1:40am UTC](https://es.discourse.group/t/github-js-choi-proposal-bigint-math-draft-specification-for-supporting/942/16 "2024-11-01T01:40:46Z")
In practice, that's always true. But in theory, a `BigInt` could be bigger than [G(64)](https://en.wikipedia.org/wiki/Graham%27s_number), as the spec places no hard-coded limits on their size. It's unfortunate that `Map` and `Set` came before `BigInt`s, because (unlike `String` and `Array`, whose `length`s fit in a 64bit register) their [internal size is unbounded, but gets converted to a `Float64` by their getter](https://tc39.es/ecma262/multipage/keyed-collections.html#sec-get-map.prototype.size) And `float`s lose fractional precision as the order-of-magnitude increases --- _[View the full topic](https://es.discourse.group/t/github-js-choi-proposal-bigint-math-draft-specification-for-supporting/942)._