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.