<p>What are the disadvantages of not being able to handle huge numbers also knows and an Integer limit like in JS? I know it's not a super common thing to run into problems like that while programming so are there no disadvantages really?</p>
<p>Credit to <a href="https://area51.stackexchange.com/users/218316/justanewbie">justANewbie</a> from some <a href="https://area51.stackexchange.com/proposals/127456/programming-language-design-and-implementation/127619#127619">inspiration</a>.</p>

<language-design><numbers><data-types>
What are the disadvantages of not handling big numbers?
CC BY-SA 4.0
2023-07-13T14:47:15.823Z
In the language or in the compiler/interpreter?
Pablo H
<p>The question asks a double negative, so I'll answer the simpler question of what advantages there are to supporting big numbers.</p>
<p>To me, the main benefit is peace of mind ─ sure, my auto-incrementing ID will probably never overflow, but what if someone runs my program for a year without rebooting? I don't want to have to think about this kind of edge case, it wastes brainpower. Then there are the situations where my integers <em>will</em> definitely overflow and I don't want them to, but the code to handle it when it happens is more complicated than it would need to be if there was no overflow.</p>
<p>If my integers are fixed width and can overflow, then everywhere I use arithmetic but don't want overflow (which is a lot of places!), I need to justify why the arithmetic in that place will give the correct result, and possibly change the code to ensure it <em>will</em>. In contrast, when I write in Python I don't need to think about this. In many circumstances, as a programmer I'm willing to trade a bit of performance for the benefit of knowing my program will produce correct answers without having to account for arithmetic operators which don't behave like their mathematical ideals.</p>
<p>Another upside is that big numbers can easily be used to simulate fixed-width numbers ─ just write <code>(x + y) &amp; 0xFFFFFFFF</code> instead of <code>x + y</code> when you want overflowing behaviour. It's much easier to discard extra bits than it is to  recover those discarded bits, or even detect that they were discarded. So just one integer type (e.g. <code>bigint</code>) is enough for the language to support whatever integer arithmetic behaviour you want.</p>

CC BY-SA 4.0
2023-05-16T22:14:39.127Z
2023-05-16T22:14:39.127Z
kaya3
<h1>Applications of &quot;big numbers&quot;</h1>
<p>The last paragraph of my answer to <a href="https://mattermodeling.stackexchange.com/a/1356/5">Did the 2019 discovery of O(N log(N)) multiplication have a practical outcome?</a> gives some examples of cases in which large integers are useful. Those cases, and other cases in which &quot;big numbers&quot; are useful, are listed in separate headings below (in no particular order).</p>
<h3>Cryptography</h3>
<p>One of the most widely known cryptographic protocols is the RSA system, and all <a href="https://en.wikipedia.org/wiki/RSA_numbers" rel="nofollow noreferrer">RSA numbers</a> are at least 100 digits long. However, RSA-100 (100 digits long) was factored in 1991 and RSA-250 (250 digits long) was factored in 2020. The recommended key size for RSA is 4096-bits or 616 digits! An enormous amount of computer security from which you benefit every day, involves computer programs that deal with numbers that are hundreds of digits long.</p>
<h3>Working with polynomials with large coefficients/powers</h3>
<p>Polynomials are used in many areas, including number-theory/cryptography, but also for approximating other functions (Chebyshev polynomials, Taylor expansions, etc.). The more terms in a Taylor series (for example), the more accurate the approximation is to the original function. However, when a polynomial in a Taylor series has a lot of terms, it's because the variables are getting raised to large powers.</p>
<p>Even if we only have a 10-term polynomial, which goes from <span class="math-container">$Ax^0$</span> to <span class="math-container">$Ax^9$</span>, what happens when we try to plug <span class="math-container">$x=1000$</span> into <span class="math-container">$x^9$</span>? We get <span class="math-container">$10^{27}$</span> which is quite a huge number, and will certainly need &quot;large integer arithmetic&quot; capabilities if you want to keep things &quot;exact&quot; as we do in <a href="https://en.wikipedia.org/wiki/Computer_algebra" rel="nofollow noreferrer">symbolic computation</a>, but even if we resort to &quot;numerical computation&quot;, the difference between <span class="math-container">$x=1000$</span> and <span class="math-container">$x=1000.000001^9$</span> <a href="https://www.wolframalpha.com/input?i=1000.000001%5E9" rel="nofollow noreferrer">is still about</a> <span class="math-container">$10^{18}$</span> which is quite big!</p>
<h3>Quadruple precision and arbitrary precision arithmetic</h3>
<p>I personally needed quadruple precision when I published <a href="https://arxiv.org/abs/1408.2276" rel="nofollow noreferrer">this paper on the ZnO molecule</a>. Measurements on such molecules can be done with a precision of <span class="math-container">$10^{10}\,\mathrm{cm}^{-1}$</span> and what I was doing, which was fitting a potential energy curve to describe the internuclear interaction between the Zn and O atoms in ZnO, to reproduce the experimental data, did not work with the state-of-the-art software at the time, so we had to switch from double to quadruple precision. Stack Overflow helped me with that, after I asked <a href="https://stackoverflow.com/q/18137127/1271772">Converting a working code from double-precision to quadruple-precision: How to read quadruple-precision numbers in FORTRAN from an input file</a> and later I asked a follow-up question on the same topic <a href="https://stackoverflow.com/q/38415703/1271772">How do I declare the precision of a number to be an adjustable parameter?</a>.</p>
<p>In my answer to <a href="https://mattermodeling.stackexchange.com/a/9061/5">How much does it cost (RAM and CPU) to calculate the energy of H2?</a> you can see another example in which arbitrary-precision arithmetic is needed. I'll provide the screenshot here so that you can see how many digits are needed before you see differences in the numbers (this is the convergence precision that the authors wanted):</p>
<p><a href="https://i.sstatic.net/AYnCC.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/AYnCC.png" alt="enter image description here" /></a></p>
<p>There's many other applications that need arbitrary-precision arithmetic. Another example is calculating the roots of a Rys polynomial for calculating electron repulsion integrals, which is crucial for tens of thousands of scientists. See the <a href="https://mpmath.org/" rel="nofollow noreferrer">mpmath</a> package and where it's used, to see more examples of uses for multi-precision arithmetic or arbitrary-precision arithmetic.</p>
<h3>Fun math</h3>
<p>Using computers for &quot;fun math&quot; like breaking records for the largest number of digits of <span class="math-container">$\pi$</span>, or computing Mandelbrot fractals, would also require support for &quot;big numbers&quot;.</p>

CC BY-SA 4.0
2023-05-16T21:07:30.090Z
2023-08-11T16:54:35.080Z
2023-08-11T16:54:35.080Z
Nike Dattani
CC BY-SA 4.0
2023-05-18T22:24:33.513Z
The bignum implementation that you'd want in a standard library is not suitable for cryptography. In most environments, cryptography requires protection against [side channels](https://en.wikipedia.org/wiki/Side-channel_attack) such as timing. You can't protect a generic bignum implementation against leaking the size of numbers, and that's bad for cryptography. Cryptography generally needs large fixnums as a primitive (e.g. work on numbers that are _exactly_ 4096 bits to implement 4096-bit RSA).
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-18T22:25:31.470Z
As a cryptography implementer, I do often make use of Python's convenient access to bignums, but only to generate test data. I would never use that in production code even if my application was written in Python.
Gilles 'SO- stop being evil'
<h3>Almost none</h3>
<p>Most major programming languages, like C#, Java and as you mentioned, JavaScript, don't support arbitrary large integers in their default namespaces/packages/... However, for all of those languages, it is possible to support that kind of arithmetic in another way (provided in another namespace/package, a third party library, or even by yourself with custom data structures).</p>
<p>It does make sense to include it by default in a language designed for problems expected to deal with large integers (computer algebra systems come to mind).</p>

CC BY-SA 4.0
2023-05-16T20:04:12.293Z
2023-05-16T20:17:07.287Z
2023-05-16T20:17:07.287Z
Glorfindel
CC BY-SA 4.0
2023-05-16T20:14:49.097Z
Modern JavaScript does have the “bigint” type, actually. I think it was introduced in ES 2017 or 2018?
Bbrk24
CC BY-SA 4.0
2023-05-16T20:14:54.943Z
[C#](https://learn.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=net-7.0), [Java](https://docs.oracle.com/javase/8/docs/api/java/math/BigInteger.html), and [Javascript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) all have big integer datatypes built-in. It's true that they don't gracefully promote regular numbers to them like some languages, but they're definitely present.
Silvio Mayolo
<p>&quot;Super common&quot; is a relative thing; I don't often use large numbers in my code, but I know people who do. It mostly depends on what your language is meant to be used for; tiny esoteric languages probably don't need to worry about it, but ones meant for general use should, because someone will inevitably end up needing it.</p>

CC BY-SA 4.0
2023-05-16T20:01:32.620Z
2023-05-16T20:01:32.620Z
Ginger
<p>Actual high-magnitude numbers aren't usually needed, but precision is much more often an issue, and the two often go together.</p>
<p>For example, using 64-bit floats to represent money amounts can quickly lead to imprecision.</p>
<p>An example of limited range being a problem is seen when using 32-bit integers to index an array. This limits the array size to 2³² which is fewer elements than, say, the number of humans on earth.</p>

CC BY-SA 4.0
2023-05-16T20:15:41.093Z
2023-05-17T04:41:10.017Z
2023-05-17T04:41:10.017Z
Adám
CC BY-SA 4.0
2023-05-18T22:31:52.287Z
@NikeDattani Sayings in the numerical community are not relevant to finance. Finance has very precise rules about calculations: you can't just round stuff the way you want. Precision is never a concern because all financial calculations are exact. (They might implement rules like “round down now to the nearest ¤.001 at this step”, but you have to follow this rule exactly, not round at the next step or round down to the nearest ¤0.0009765625.)
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-18T22:43:23.370Z
@Gilles'SO-stopbeingevil' are you able to provide a reference that supports Adám's claim?
Nike Dattani
CC BY-SA 4.0
2023-05-18T22:47:37.860Z
@NikeDattani [1](https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency) [2](https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio) [3](https://www.reddit.com/r/programming/comments/i6i0h/why_we_dont_use_doubles_for_financial_calculations/) ...
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-19T20:23:04.803Z
@Gilles'SO-stopbeingevil' the first thread contained this (I presume you already know about it, but I'm writing it here for completeness): "This is not a matter of accuracy, nor is it a matter of precision. It is a matter of meeting the expectations of humans who use base 10 for calculations instead of base 2", and after reading more of that thread it seems that the finance calculations don't need quadruple precision, or "big numbers", but there's a preference to use exact integer arithmetic rather than floating point arithmetic. Is that right?
Nike Dattani
CC BY-SA 4.0
2023-05-20T19:28:46.330Z
@NikeDattani It's not just a preference, it's a rule. If you don't use the specific rounding rules mandated by the law/contract, your accounting is wrong. Most calculations don't need a lot of digits, but they're all significant.
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-20T21:28:41.547Z
@Gilles'SO-stopbeingevil' (1) the rule is a preference. (2) Is it correct that "big numbers" or "quadruple precision" is not what's needed? What's needed instead are the specific rounding rules, which don't involve "big numbers"?
Nike Dattani
CC BY-SA 4.0
2023-05-20T21:47:54.317Z
@NikeDattani (1) No, it's a legal requirement. (2) Indeed this doesn't mean that you need a larger range for numbers (most financial calculations don't need more than 64 value bits). It means that if you need a larger range, floating point is not a solution.
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-21T03:11:36.227Z
@Gilles'SO-stopbeingevil' (1) I'd argue that the law is a preference of the lawmakers, but the main point relevant to this question is (2): I'd argue that for ***all*** meaningful financial calculations, 64-bits is enough meaning that there's no need for a "larger range" or "big numbers". I'd be very happy to change my mind if I see a convincing reference showing that 64-bit calculations aren't enough for a meaningful financial application (apart from anything related to legal requirements). The answer says "using 64-bit floats to represent money amounts can quickly lead to imprecision."
Nike Dattani
CC BY-SA 4.0
2023-05-21T22:40:29.497Z
@NikeDattani I don't see how a meaningful financial application would ignore legal requirements. The exact value of the US GDP are both 52 bits long in cents (26 trillion * 100), and the world GDP is 54 bits long (96 trillion * 100), and since a double only has 53 bits of precision, meaningful operations to the exact cent are already  risky or impossible with real world amounts in double precision.
prosfilaes
CC BY-SA 4.0
2023-05-22T03:56:35.983Z
@prosfilaes is the law the same everywhere in the world? Does the GDP of the world ever get measured in cents? Or is it measured, reported, and analyzed in trillions of dollars?
Nike Dattani
CC BY-SA 4.0
2023-05-22T12:29:27.437Z
@NikeDattani Is there any reason to think that the law anywhere doesn't require exact precision? It's certainly true in most of the places where people will be using financial software.
prosfilaes
CC BY-SA 4.0
2023-05-22T12:40:34.807Z
@NikeDattani It's certainly not measured in trillions of dollars. A quick search would tell you that. Statista reports it to the nearest ten million dollars, and the calculators would have worked most likely to the dollar precision; you round at the end of a calculation. Money is starting to get into the range where precision may demand more than a double precision number can handle, and there's no reason to handwave the fine details when you can get them right.
prosfilaes
CC BY-SA 4.0
2023-05-22T16:20:23.717Z
Prosfilaes, thanks for proving my point. Double precision is far, far more than enough for numbers in the tens of trillions, reported to the nearest tens of millions.
Nike Dattani
CC BY-SA 4.0
2023-05-24T03:45:51.500Z
@NikeDattani Above you asked for "measured, reported, and analyzed".  It is not measured and analyzed, as your own specifications called for, in tens of millions.  You're arguing that 53 bits of precision "ought to be enough for anybody", when it's obviously not, and the cases where it's not are likely to be more common in the future.
prosfilaes
CC BY-SA 4.0
2023-05-24T03:54:18.200Z
@prosfilaes you have expressed your opinion. I disagree with it. Single-precision is enough for all meaningful calculations associated with GDP. Double-precision would be overkill. You don't need to keep pinging me.
Nike Dattani
CC BY-SA 4.0
2023-05-24T04:10:47.913Z
Nike Dattani, single precision can't even calculate a large tax bill; no more than six significant decimal digits can round trip through single-precision float. A programmer setting what's good enough at lower level than his users want is a problem. Please continue pinging me, as is standard for StackExchange.
prosfilaes
CC BY-SA 4.0
2023-05-24T09:48:20.653Z
A tax bill is not the same as a GDP.
Nike Dattani
CC BY-SA 4.0
2023-05-24T17:22:47.580Z
@NikeDattani Apple is valued at three trillion dollars, so it's not that far off. But we'll never need more than two digits for the year, right?
prosfilaes
CC BY-SA 4.0
2023-05-24T18:32:45.480Z
Apple does not pay 3 trillion dollars in taxes. Also, I would like for you to stop pinging me.
Nike Dattani
CC BY-SA 4.0
2023-05-27T22:06:35.607Z
@NikeDattani The tax bill is based off that three trillion figure. Also, I asked for you to continue pinging me; courtesy goes both ways.
prosfilaes
CC BY-SA 4.0
2023-05-28T00:09:37.917Z
Not all digits of the 3 trillion figure are taken into account, for anything. Even if they were, you are **multiple orders of magnitude away** from where double precision becomes limited.
Nike Dattani
CC BY-SA 4.0
2023-05-29T23:04:58.800Z
@NikeDattani If you don't care about getting the right answer, then you don't have to worry about all the digits. Accountants do care about getting the correct answer, to the cent. It's easy to lose those digits if you multiple by a numerator before dividing by a denominator, instead of converting the fraction to a real number. Easy to fix, but an easy to overlook bug. Also, inflation keeps those numbers going up.
prosfilaes
CC BY-SA 4.0
2023-05-30T02:03:11.720Z
It's a public company. Can you find any number that's in the trillions and precise in the cents digits?
Nike Dattani
CC BY-SA 4.0
2023-07-26T15:44:16.240Z
Apple's valuation is the number of shares (which should be a known exact integer), multiplied by the price per share (which is an integer number of cents, that changes several times a minute). At the moment it's just below 20,000 cents, so the smallest possible change in the valuation would be 3 trillion divided by 20,000 = 150 million dollars.
gnasher729
CC BY-SA 4.0
2023-07-26T15:46:55.463Z
Double precision handles all integers up to 2^53. 2^53 cents is about 80 trillion dollars. But then signed 64 bit integers go up to 2^63, that's 1024 times further.
gnasher729
CC BY-SA 4.0
2023-07-26T15:49:21.093Z
In the UK, if you pay 20% VAT on 10 items for £9.99 each, you need to decide at some point consistently for your company whether you pay 10 times £2.00 VAT = £20,00, or 20% of £99.90 = £19.98. Each is easy enough. And it's decided by tax rules, not by your floating-point arithmetic.
gnasher729
CC BY-SA 4.0
2023-07-26T15:51:34.340Z
@NikeDattani Single precision is not enough if you have floating point errors that add up. If you add a billion values from \$0.00 to \$9.99, then single precision will end up fatally imprecise. Actually, at $2^{35}$ cents the sum stops increasing if you add \$9.99 so you will never have more than about 320 million dollars.
gnasher729
CC BY-SA 4.0
2023-05-16T20:20:58.603Z
+1 but do you have a reference for "For example, using 64-bit floats to represent money amounts can quickly lead to imprecision" ? There's a saying in the numerical computing community: single-precision is good enough 90% of the time, double-precision is enough 99.99% of the time (or something like that). Anything beyond 64-bits is beyond double-precision, which is rarely needed for anything (but I'm not saying it's never needed, because there's many examples that do need quadruple precision for example).
Nike Dattani
CC BY-SA 4.0
2023-05-16T20:24:48.273Z
@NikeDattani Yes, I've heard directly from one of our major customers in the finance industry that they in turn have portfolios with amounts that approach the precision of 64-bit floats.
Adám
CC BY-SA 4.0
2023-05-16T20:28:40.840Z
That's hearsay. I've heard many people claiming that they need quadruple precision, when in fact they were just using a bad algorithm or a poor implementation of a good algorithm. If quadruple-precision or anything beyond double-precision is needed in any financial application, then there ought to be a good reference for it that we can find online right?
Nike Dattani
<p>Computers are designed to be maximally efficient at dealing with objects of known size, or at least a known fixed maximum size.  By way of analogy, imagine one is managing a workshop with a large open floor area where people will be building various project of different sizes.</p>
<p>If requesting space to build a project must specify in advance how much space they will need, then one can assign a location for each project when space is involved, and anyone who needs to order supplies will be able to say when placing the order where they should be delivered, allowing the delivery agent to go directly to that location.</p>
<p>If it isn't possible to specify the space requirement for a project in advance, and the project grows to the point that will no longer fit in the space that's &quot;boxed in&quot; by the projects around it, it will be necessary for it to move somewhere else.  If this might happen when anybody has a copy of the object's location and is expecting to go there or deliver something, it will be necessary to either:</p>
<ol>
<li><p>Find all copies of the location that exist anywhere in the universe and change them to so they instead report the new location.</p>
</li>
<li><p>Leave a marker at the old location, refrain from reusing the space as long as any references exist to the old location, and require that anyone making a delivery look for a note to see if the object has moved, rather than blindly dropping off the shipment.</p>
</li>
</ol>
<p>To simplify #1, one might specify that nobody other than the main office is allowed to persist any information related to the project's location, and require that the delivery agent only ask for the project's location when it's ready to make an immediate delivery, and say that if a project would need to expand between the time a delivery agent has inquired about its location and the time delivery is complete, the expansion would need to wait until the delivery is done.</p>
<p>It's possible for memory-management systems to use a combination of the two approaches to manage flexibly-sized objects, but it makes many kinds of operations much more complicated than they would be if all objects were assigned a certain amount of space when they were created and would never need to expand beyond that.</p>

CC BY-SA 4.0
2023-08-15T15:43:07.970Z
2023-08-15T15:43:07.970Z
supercat
CC BY-SA 4.0
2023-08-15T16:04:14.560Z
I don't see how this is relevant to numbers, which are normally immutable. If e.g. a bigint object is allocated on the heap, then the number that object represents can't get bigger or need to be reallocated, so references to it won't need to be updated. Instead, if a bigger number is needed then a new bigint object will be allocated for it, and pre-existing references to the old number will stay referring to the old object.
kaya3
CC BY-SA 4.0
2023-08-15T16:13:53.543Z
@kaya3: Suppose a project has five numbers associated with it.  If there's space within the project to hold all of the numbers, someone who wants to read them can go there and see them all.  If numbers are variable-sized, someone visiting the project to read the five numbers would need to go first to the project, and then go to five more places to read the numbers.
supercat
# What are the disadvantages of not handling big numbers?
Posted by: username_0 on 2023-05-16
What are the disadvantages of not being able to handle huge numbers also knows and an Integer limit like in JS? I know it's not a super common thing to run into problems like that while programming so are there no disadvantages really?

Credit to [justANewbie](https://area51.stackexchange.com/users/218316/justanewbie) from some [inspiration](https://area51.stackexchange.com/proposals/127456/programming-language-design-and-implementation/127619#127619).
**Tags:** language-design numbers data-types
> **Comments:**
> **username_1**: In the language or in the compiler/interpreter?  
---
## 6 answers
### Answer by username_3 on 2023-05-16. Score: 14
# Applications of "big numbers"

The last paragraph of my answer to [Did the 2019 discovery of O(N log(N)) multiplication have a practical outcome?](https://mattermodeling.stackexchange.com/a/1356/5) gives some examples of cases in which large integers are useful. Those cases, and other cases in which "big numbers" are useful, are listed in separate headings below (in no particular order).

### Cryptography

One of the most widely known cryptographic protocols is the RSA system, and all [RSA numbers](https://en.wikipedia.org/wiki/RSA_numbers) are at least 100 digits long. However, RSA-100 (100 digits long) was factored in 1991 and RSA-250 (250 digits long) was factored in 2020. The recommended key size for RSA is 4096-bits or 616 digits! An enormous amount of computer security from which you benefit every day, involves computer programs that deal with numbers that are hundreds of digits long.

### Working with polynomials with large coefficients/powers

Polynomials are used in many areas, including number-theory/cryptography, but also for approximating other functions (Chebyshev polynomials, Taylor expansions, etc.). The more terms in a Taylor series (for example), the more accurate the approximation is to the original function. However, when a polynomial in a Taylor series has a lot of terms, it's because the variables are getting raised to large powers.

Even if we only have a 10-term polynomial, which goes from $Ax^0$ to $Ax^9$, what happens when we try to plug $x=1000$ into $x^9$? We get $10^{27}$ which is quite a huge number, and will certainly need "large integer arithmetic" capabilities if you want to keep things "exact" as we do in [symbolic computation](https://en.wikipedia.org/wiki/Computer_algebra), but even if we resort to "numerical computation", the difference between $x=1000$ and $x=1000.000001^9$ [is still about](https://www.wolframalpha.com/input?i=1000.000001%5E9) $10^{18}$ which is quite big!

### Quadruple precision and arbitrary precision arithmetic

I personally needed quadruple precision when I published [this paper on the ZnO molecule](https://arxiv.org/abs/1408.2276). Measurements on such molecules can be done with a precision of $10^{10}\,\mathrm{cm}^{-1}$ and what I was doing, which was fitting a potential energy curve to describe the internuclear interaction between the Zn and O atoms in ZnO, to reproduce the experimental data, did not work with the state-of-the-art software at the time, so we had to switch from double to quadruple precision. Stack Overflow helped me with that, after I asked [Converting a working code from double-precision to quadruple-precision: How to read quadruple-precision numbers in FORTRAN from an input file](https://stackoverflow.com/q/18137127/1271772) and later I asked a follow-up question on the same topic [How do I declare the precision of a number to be an adjustable parameter?](https://stackoverflow.com/q/38415703/1271772).

In my answer to [How much does it cost (RAM and CPU) to calculate the energy of H2?](https://mattermodeling.stackexchange.com/a/9061/5) you can see another example in which arbitrary-precision arithmetic is needed. I'll provide the screenshot here so that you can see how many digits are needed before you see differences in the numbers (this is the convergence precision that the authors wanted):

[![enter image description here](https://i.sstatic.net/AYnCC.png)](https://i.sstatic.net/AYnCC.png)

There's many other applications that need arbitrary-precision arithmetic. Another example is calculating the roots of a Rys polynomial for calculating electron repulsion integrals, which is crucial for tens of thousands of scientists. See the [mpmath](https://mpmath.org/) package and where it's used, to see more examples of uses for multi-precision arithmetic or arbitrary-precision arithmetic.

### Fun math

Using computers for "fun math" like breaking records for the largest number of digits of $\pi$, or computing Mandelbrot fractals, would also require support for "big numbers".
> **Comments:**
> **username_4** (2023-05-18): The bignum implementation that you'd want in a standard library is not suitable for cryptography. In most environments, cryptography requires protection against [side channels](https://en.wikipedia.org/wiki/Side-channel_attack) such as timing. You can't protect a generic bignum implementation against leaking the size of numbers, and that's bad for cryptography. Cryptography generally needs large fixnums as a primitive (e.g. work on numbers that are _exactly_ 4096 bits to implement 4096-bit RSA).  
> **username_4** (2023-05-18): As a cryptography implementer, I do often make use of Python's convenient access to bignums, but only to generate test data. I would never use that in production code even if my application was written in Python.  
---
### Answer by username_2 on 2023-05-16. Score: 9
The question asks a double negative, so I'll answer the simpler question of what advantages there are to supporting big numbers.

To me, the main benefit is peace of mind ─ sure, my auto-incrementing ID will probably never overflow, but what if someone runs my program for a year without rebooting? I don't want to have to think about this kind of edge case, it wastes brainpower. Then there are the situations where my integers *will* definitely overflow and I don't want them to, but the code to handle it when it happens is more complicated than it would need to be if there was no overflow.

If my integers are fixed width and can overflow, then everywhere I use arithmetic but don't want overflow (which is a lot of places!), I need to justify why the arithmetic in that place will give the correct result, and possibly change the code to ensure it *will*. In contrast, when I write in Python I don't need to think about this. In many circumstances, as a programmer I'm willing to trade a bit of performance for the benefit of knowing my program will produce correct answers without having to account for arithmetic operators which don't behave like their mathematical ideals.

Another upside is that big numbers can easily be used to simulate fixed-width numbers ─ just write `(x + y) & 0xFFFFFFFF` instead of `x + y` when you want overflowing behaviour. It's much easier to discard extra bits than it is to recover those discarded bits, or even detect that they were discarded. So just one integer type (e.g. `bigint`) is enough for the language to support whatever integer arithmetic behaviour you want.
---
### Answer by username_8 on 2023-05-16. Score: 8
"Super common" is a relative thing; I don't often use large numbers in my code, but I know people who do. It mostly depends on what your language is meant to be used for; tiny esoteric languages probably don't need to worry about it, but ones meant for general use should, because someone will inevitably end up needing it.
---
### Answer by username_9 on 2023-05-16. Score: 8
Actual high-magnitude numbers aren't usually needed, but precision is much more often an issue, and the two often go together.

For example, using 64-bit floats to represent money amounts can quickly lead to imprecision.

An example of limited range being a problem is seen when using 32-bit integers to index an array. This limits the array size to 2³² which is fewer elements than, say, the number of humans on earth.
> **Comments:**
> **username_3** (2023-05-16): +1 but do you have a reference for "For example, using 64-bit floats to represent money amounts can quickly lead to imprecision" ? There's a saying in the numerical computing community: single-precision is good enough 90% of the time, double-precision is enough 99.99% of the time (or something like that). Anything beyond 64-bits is beyond double-precision, which is rarely needed for anything (but I'm not saying it's never needed, because there's many examples that do need quadruple precision for example).  
> **username_9** (2023-05-16): @NikeDattani Yes, I've heard directly from one of our major customers in the finance industry that they in turn have portfolios with amounts that approach the precision of 64-bit floats.  
> **username_3** (2023-05-16): That's hearsay. I've heard many people claiming that they need quadruple precision, when in fact they were just using a bad algorithm or a poor implementation of a good algorithm. If quadruple-precision or anything beyond double-precision is needed in any financial application, then there ought to be a good reference for it that we can find online right?  
> **username_4** (2023-05-18): @NikeDattani Sayings in the numerical community are not relevant to finance. Finance has very precise rules about calculations: you can't just round stuff the way you want. Precision is never a concern because all financial calculations are exact. (They might implement rules like “round down now to the nearest ¤.001 at this step”, but you have to follow this rule exactly, not round at the next step or round down to the nearest ¤0.0009765625.)  
> **username_3** (2023-05-18): @Gilles'SO-stopbeingevil' are you able to provide a reference that supports Adám's claim?  
> **username_4** (2023-05-18): @NikeDattani [1](https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency) [2](https://dzone.com/articles/never-use-float-and-double-for-monetary-calculatio) [3](https://www.reddit.com/r/programming/comments/i6i0h/why_we_dont_use_doubles_for_financial_calculations/) ...  
> **username_3** (2023-05-19): @Gilles'SO-stopbeingevil' the first thread contained this (I presume you already know about it, but I'm writing it here for completeness): "This is not a matter of accuracy, nor is it a matter of precision. It is a matter of meeting the expectations of humans who use base 10 for calculations instead of base 2", and after reading more of that thread it seems that the finance calculations don't need quadruple precision, or "big numbers", but there's a preference to use exact integer arithmetic rather than floating point arithmetic. Is that right?  
> **username_4** (2023-05-20): @NikeDattani It's not just a preference, it's a rule. If you don't use the specific rounding rules mandated by the law/contract, your accounting is wrong. Most calculations don't need a lot of digits, but they're all significant.  
> **username_3** (2023-05-20): @Gilles'SO-stopbeingevil' (1) the rule is a preference. (2) Is it correct that "big numbers" or "quadruple precision" is not what's needed? What's needed instead are the specific rounding rules, which don't involve "big numbers"?  
> **username_4** (2023-05-20): @NikeDattani (1) No, it's a legal requirement. (2) Indeed this doesn't mean that you need a larger range for numbers (most financial calculations don't need more than 64 value bits). It means that if you need a larger range, floating point is not a solution.  
> **username_3** (2023-05-21): @Gilles'SO-stopbeingevil' (1) I'd argue that the law is a preference of the lawmakers, but the main point relevant to this question is (2): I'd argue that for ***all*** meaningful financial calculations, 64-bits is enough meaning that there's no need for a "larger range" or "big numbers". I'd be very happy to change my mind if I see a convincing reference showing that 64-bit calculations aren't enough for a meaningful financial application (apart from anything related to legal requirements). The answer says "using 64-bit floats to represent money amounts can quickly lead to imprecision."  
> **username_10** (2023-05-21): @NikeDattani I don't see how a meaningful financial application would ignore legal requirements. The exact value of the US GDP are both 52 bits long in cents (26 trillion * 100), and the world GDP is 54 bits long (96 trillion * 100), and since a double only has 53 bits of precision, meaningful operations to the exact cent are already  risky or impossible with real world amounts in double precision.  
> **username_3** (2023-05-22): @prosfilaes is the law the same everywhere in the world? Does the GDP of the world ever get measured in cents? Or is it measured, reported, and analyzed in trillions of dollars?  
> **username_10** (2023-05-22): @NikeDattani Is there any reason to think that the law anywhere doesn't require exact precision? It's certainly true in most of the places where people will be using financial software.  
> **username_10** (2023-05-22): @NikeDattani It's certainly not measured in trillions of dollars. A quick search would tell you that. Statista reports it to the nearest ten million dollars, and the calculators would have worked most likely to the dollar precision; you round at the end of a calculation. Money is starting to get into the range where precision may demand more than a double precision number can handle, and there's no reason to handwave the fine details when you can get them right.  
> **username_3** (2023-05-22): Prosfilaes, thanks for proving my point. Double precision is far, far more than enough for numbers in the tens of trillions, reported to the nearest tens of millions.  
> **username_10** (2023-05-24): @NikeDattani Above you asked for "measured, reported, and analyzed".  It is not measured and analyzed, as your own specifications called for, in tens of millions.  You're arguing that 53 bits of precision "ought to be enough for anybody", when it's obviously not, and the cases where it's not are likely to be more common in the future.  
> **username_3** (2023-05-24): @prosfilaes you have expressed your opinion. I disagree with it. Single-precision is enough for all meaningful calculations associated with GDP. Double-precision would be overkill. You don't need to keep pinging me.  
> **username_10** (2023-05-24): Nike Dattani, single precision can't even calculate a large tax bill; no more than six significant decimal digits can round trip through single-precision float. A programmer setting what's good enough at lower level than his users want is a problem. Please continue pinging me, as is standard for StackExchange.  
> **username_3** (2023-05-24): A tax bill is not the same as a GDP.  
> **username_10** (2023-05-24): @NikeDattani Apple is valued at three trillion dollars, so it's not that far off. But we'll never need more than two digits for the year, right?  
> **username_3** (2023-05-24): Apple does not pay 3 trillion dollars in taxes. Also, I would like for you to stop pinging me.  
> **username_10** (2023-05-27): @NikeDattani The tax bill is based off that three trillion figure. Also, I asked for you to continue pinging me; courtesy goes both ways.  
> **username_3** (2023-05-28): Not all digits of the 3 trillion figure are taken into account, for anything. Even if they were, you are **multiple orders of magnitude away** from where double precision becomes limited.  
> **username_10** (2023-05-29): @NikeDattani If you don't care about getting the right answer, then you don't have to worry about all the digits. Accountants do care about getting the correct answer, to the cent. It's easy to lose those digits if you multiple by a numerator before dividing by a denominator, instead of converting the fraction to a real number. Easy to fix, but an easy to overlook bug. Also, inflation keeps those numbers going up.  
> **username_3** (2023-05-30): It's a public company. Can you find any number that's in the trillions and precise in the cents digits?  
> **username_11** (2023-07-26): Apple's valuation is the number of shares (which should be a known exact integer), multiplied by the price per share (which is an integer number of cents, that changes several times a minute). At the moment it's just below 20,000 cents, so the smallest possible change in the valuation would be 3 trillion divided by 20,000 = 150 million dollars.  
> **username_11** (2023-07-26): Double precision handles all integers up to 2^53. 2^53 cents is about 80 trillion dollars. But then signed 64 bit integers go up to 2^63, that's 1024 times further.  
> **username_11** (2023-07-26): In the UK, if you pay 20% VAT on 10 items for £9.99 each, you need to decide at some point consistently for your company whether you pay 10 times £2.00 VAT = £20,00, or 20% of £99.90 = £19.98. Each is easy enough. And it's decided by tax rules, not by your floating-point arithmetic.  
> **username_11** (2023-07-26): @NikeDattani Single precision is not enough if you have floating point errors that add up. If you add a billion values from \$0.00 to \$9.99, then single precision will end up fatally imprecise. Actually, at $2^{35}$ cents the sum stops increasing if you add \$9.99 so you will never have more than about 320 million dollars.  
---
### Answer by username_5 on 2023-05-16. Score: 6
### Almost none

Most major programming languages, like C#, Java and as you mentioned, JavaScript, don't support arbitrary large integers in their default namespaces/packages/... However, for all of those languages, it is possible to support that kind of arithmetic in another way (provided in another namespace/package, a third party library, or even by yourself with custom data structures).

It does make sense to include it by default in a language designed for problems expected to deal with large integers (computer algebra systems come to mind).
> **Comments:**
> **username_6** (2023-05-16): Modern JavaScript does have the “bigint” type, actually. I think it was introduced in ES 2017 or 2018?  
> **username_7** (2023-05-16): [C#](https://learn.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=net-7.0), [Java](https://docs.oracle.com/javase/8/docs/api/java/math/BigInteger.html), and [Javascript](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt) all have big integer datatypes built-in. It's true that they don't gracefully promote regular numbers to them like some languages, but they're definitely present.  
---
### Answer by username_12 on 2023-08-15. Score: 2
Computers are designed to be maximally efficient at dealing with objects of known size, or at least a known fixed maximum size. By way of analogy, imagine one is managing a workshop with a large open floor area where people will be building various project of different sizes.

If requesting space to build a project must specify in advance how much space they will need, then one can assign a location for each project when space is involved, and anyone who needs to order supplies will be able to say when placing the order where they should be delivered, allowing the delivery agent to go directly to that location.

If it isn't possible to specify the space requirement for a project in advance, and the project grows to the point that will no longer fit in the space that's "boxed in" by the projects around it, it will be necessary for it to move somewhere else. If this might happen when anybody has a copy of the object's location and is expecting to go there or deliver something, it will be necessary to either:

1. Find all copies of the location that exist anywhere in the universe and change them to so they instead report the new location.
2. Leave a marker at the old location, refrain from reusing the space as long as any references exist to the old location, and require that anyone making a delivery look for a note to see if the object has moved, rather than blindly dropping off the shipment.

To simplify #1, one might specify that nobody other than the main office is allowed to persist any information related to the project's location, and require that the delivery agent only ask for the project's location when it's ready to make an immediate delivery, and say that if a project would need to expand between the time a delivery agent has inquired about its location and the time delivery is complete, the expansion would need to wait until the delivery is done.

It's possible for memory-management systems to use a combination of the two approaches to manage flexibly-sized objects, but it makes many kinds of operations much more complicated than they would be if all objects were assigned a certain amount of space when they were created and would never need to expand beyond that.
> **Comments:**
> **username_2** (2023-08-15): I don't see how this is relevant to numbers, which are normally immutable. If e.g. a bigint object is allocated on the heap, then the number that object represents can't get bigger or need to be reallocated, so references to it won't need to be updated. Instead, if a bigger number is needed then a new bigint object will be allocated for it, and pre-existing references to the old number will stay referring to the old object.  
> **username_12** (2023-08-15): @kaya3: Suppose a project has five numbers associated with it.  If there's space within the project to hold all of the numbers, someone who wants to read them can go there and see them all.  If numbers are variable-sized, someone visiting the project to read the five numbers would need to go first to the project, and then go to five more places to read the numbers.  
---
