Strictly speaking, this should not be solved by fixed-precision numeric libraries where the precision has to be manually set to a large value; although if this is the only recourse then it may be used with a note explaining that the precision must be set manually to a large enough value.

"Strictly speaking, this should not be solved by fixed-precision numeric libraries where the precision has to be manually set to a large value; although if this is the only recourse then it may be used with a note explaining that the precision must be set manually to a large enough value."

Now one should always speak strictly, especially to animals and small children and, strictly speaking, Algol 68 Genie requires that a non-default numeric precision for a LONGLONGINT be specified by"precision=<integral denotation>" either in a source code PRAGMAT or as a command line argument. However, that specification need not be made manually. This snippet of code outputs an appropriate PRAGMAT

This is done in pure C. The multiplication code is slow (grade school, just done using strings),
but since the text representation was required, it is MUCH easier to do it this way, than to have
to implement division and modulus to convert a base 2^32 number into base-10.

This entry might be pushing the limits of the spirit of the task. COBOL does not have arbitrary-precision integers in the spec, but it does mandate a precision of some 1000 digits with intermediate results, from 10^-999 through 10^1000, for purposes of rounding financially sound decimal arithmetic. GnuCOBOL uses libgmp or equivalent to meet and surpass this requirement, but this precision is not exposed to general programming in the language. The capabilities are included in the GnuCOBOL implementation run-time support, but require access to some of the opaque features of libgmp for use in this task.

This listing includes a few calculations, 12345**9 is an example that demonstrates the difference between the library's view of certain string lengths and a native C view of the data.

Emacs Lisp has no big integers (bignums) in the language; but GNU Emacs 22 includes Calc, a library that implements big integers. The calc-eval function takes an algebraic formula in a string, and returns the result in a string.

Like Rexx, NetRexx comes with built-in support for numbers that can be manually set to very large values of precision.
Compared to the two methods shown above however, the performance is extremely poor.

;- 4^3^2 is withing 32 bit range, so normal procedures can be usedn=Pow(4,Pow(3,2))

;- 5^n is larger then 31^2, so the same library call as in the "Long multiplication" task is used*a=PowerDecimal(IntegerToDecimal(5),IntegerToDecimal(n))

;- Convert the large number into a string & present the resultsout$=DecimalToString(*a)L$ =Left(out$,20)R$ =Right(out$,20)digits=Str(Len(out$))out$="First 20 & last 20 chars of 5^4^3^2 are;"+#CRLF$+L$+#CRLF$+R$+#CRLF$out$+"and the result is "+digits+" digits long."

Python comes with built-in support for arbitrary precision integers. The type of arbitrary precision integers is long in Python 2.x (overflowing operations on int's are automatically converted into long's), and int in Python 3.x.

REXX comes with built-in support for fixed precision integers that can be manually set to a large value of precision (digits).
Most REXXes have a practical limit of around eight million bytes, but that is mostly an underlying limitation of addressing virtual storage.

Scala does not come with support for arbitrary precision integers powered to arbitrary precision integers, except if performed on a module. It can use arbitrary precision integers in other ways, including powering them to 32-bits integers.

There are no infix arithmetic operators in the language, but there is a power function in the bcd library, which is part of the standard distribution from the home site.

There is no distinction between ordinary and arbitrary precision integers, but the binary converted decimal representation used here is more efficient than the usual binary representation in calculations that would otherwise be dominated by the conversion to decimal output.