大数运算（整数）

BigInteger Struct (System.Numerics) | Microsoft Docs https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=netcore-3.1

Remarks

The BigInteger type is an immutable type that represents an arbitrarily large integer whose value in theory has no upper or lower bounds. The members of the BigInteger type closely parallel those of other integral types (the Byte, Int16, Int32, Int64, SByte, UInt16, UInt32, and UInt64 types). This type differs from the other integral types in the .NET Framework, which have a range indicated by their MinValue and MaxValue properties.

 Note

Because the BigInteger type is immutable (see Mutability and the BigInteger Structure) and because it has no upper or lower bounds, an OutOfMemoryException can be thrown for any operation that causes a BigInteger value to grow too large.

 BigInteger (Java SE 10 & JDK 10 ) https://docs.oracle.com/javase/10/docs/api/java/math/BigInteger.html

((64**89%(13*19))**17)%(13*19)

python3.7 64bits  返回64 ok

浏览器没有

i=int(''.join(str(i) for i in range(9999))).__sizeof__()
ii=2



optimization - Handling very large numbers in Python - Stack Overflow https://stackoverflow.com/questions/538551/handling-very-large-numbers-in-python

Python floats are neither arbitary precision nor of unlimited size. When k = 349, 16.**k is much too large - that's almost 2^1400. Fortunately, the decimal library allows arbitrary precision and can handle the size:

import decimal
decimal.getcontext().prec = 100
def pi():
    pi = decimal.Decimal(0)
    for k in range(350):
        pi += (decimal.Decimal(4)/(decimal.Decimal(8)*decimal.Decimal(k+1))...)

PEP 237 -- Unifying Long Integers and Integers | Python.org https://www.python.org/dev/peps/pep-0237/

Abstract

Python currently distinguishes between two kinds of integers (ints): regular or short ints, limited by the size of a C long (typically 32 or 64 bits), and long ints, which are limited only by available memory. When operations on short ints yield results that don't fit in a C long, they raise an error. There are some other distinctions too. This PEP proposes to do away with most of the differences in semantics, unifying the two types from the perspective of the Python user.

Rationale

Many programs find a need to deal with larger numbers after the fact, and changing the algorithms later is bothersome. It can hinder performance in the normal case, when all arithmetic is performed using long ints whether or not they are needed.

Having the machine word size exposed to the language hinders portability. For examples Python source files and .pyc's are not portable between 32-bit and 64-bit machines because of this.

There is also the general desire to hide unnecessary details from the Python user when they are irrelevant for most applications. An example is memory allocation, which is explicit in C but automatic in Python, giving us the convenience of unlimited sizes on strings, lists, etc. It makes sense to extend this convenience to numbers.

It will give new Python programmers (whether they are new to programming in general or not) one less thing to learn before they can start using the language.

Implementation

Initially, two alternative implementations were proposed (one by each author):

1. The PyInt type's slot for a C long will be turned into a:

   union {
       long i;
       struct {
           unsigned long length;
           digit digits[1];
       } bignum;
   };
   

   Only the n-1 lower bits of the long have any meaning; the top bit is always set. This distinguishes the union. All PyIntfunctions will check this bit before deciding which types of operations to use.

2. The existing short and long int types remain, but operations return a long int instead of raising OverflowError when a result cannot be represented as a short int. A new type, integer, may be introduced that is an abstract base type of which both the int and long implementation types are subclassed. This is useful so that programs can check integer-ness with a single test:

   if isinstance(i, integer): ...
   

After some consideration, the second implementation plan was selected, since it is far easier to implement, is backwards compatible at the C API level, and in addition can be implemented partially as a transitional measure.