Testing latest pari + WASM + node.js... and it works?! Wow.
License: GPL3
ubuntu2004
Function: _def_realbitprecision
Class: default
Section: default
C-Name: sd_realbitprecision
Prototype:
Help:
Doc: the number of significant bits used to convert exact inputs given to
transcendental functions (see \secref{se:trans}), or to create
absolute floating point constants (input as \kbd{1.0} or \kbd{Pi} for
instance). Unless you tamper with the \tet{format} default, this is also
the number of significant bits used to print a \typ{REAL} number;
\kbd{format} will override this latter behavior, and allow you to have a
large internal precision while outputting few digits for instance.
Note that most PARI's functions currently handle precision on a word basis (by
increments of 32 or 64 bits), hence bit precision may be a little larger
than the number of bits you expected. For instance to get 10 bits of
precision, you need one word of precision which, on a 64-bit machine,
correspond to 64 bits. To make things even more confusing, this internal bit
accuracy is converted to decimal digits when printing floating point numbers:
now 64 bits correspond to 19 printed decimal digits
($19 < \log_{10}(2^{64}) < 20$).
The value returned when typing \kbd{default(realbitprecision)} is the internal
number of significant bits, not the number of printed decimal digits:
\bprog
? default(realbitprecision, 10)
? \pb
realbitprecision = 64 significant bits
? default(realbitprecision)
%1 = 64
? \p
realprecision = 3 significant digits
? default(realprecision)
%2 = 19
@eprog\noindent Note that \tet{realprecision} and \kbd{\bs p} allow
to view and manipulate the internal precision in decimal digits.
The default value is \kbd{128}, resp.~\kbd{96}, on a 64-bit, resp~.32-bit,
machine.