Function: localbitprec
Section: programming/specific
C-Name: localbitprec
Prototype: vL
Help: localbitprec(p): set the real precision to p bits in the dynamic scope.
Doc: set the real precision to $p$ bits in the dynamic scope. All computations
are performed as if \tet{realbitprecision} was $p$:
transcendental constants (e.g.~\kbd{Pi}) and
conversions from exact to floating point inexact data use $p$ bits, as well as
iterative routines implicitly using a floating point
accuracy as a termination criterion (e.g.~\tet{solve} or \tet{intnum}).
But \kbd{realbitprecision} itself is unaffected
and is ``unmasked'' when we exit the dynamic (\emph{not} lexical) scope.
In effect, this is similar to
\bprog
my(bit = default(realbitprecision));
default(realbitprecision,p);
...
default(realbitprecision, bit);
@eprog\noindent but is both less cumbersome, cleaner (no need to manipulate
a global variable, which in fact never changes and is only temporarily masked)
and more robust: if the above computation is interrupted or an exception
occurs, \kbd{realbitprecision} will not be restored as intended.
Such \kbd{localbitprec} statements can be nested, the innermost one taking
precedence as expected. Beware that \kbd{localbitprec} follows the semantic of
\tet{local}, not \tet{my}: a subroutine called from \kbd{localbitprec} scope
uses the local accuracy:
\bprog
? f()=bitprecision(1.0);
? f()
%2 = 128
? localbitprec(1000); f()
%3 = 1024
@eprog\noindent Note that the bit precision of \emph{data} (\kbd{1.0} in the
above example) increases by steps of 64 (32 on a 32-bit machine) so we get
$1024$ instead of the expected $1000$; \kbd{localbitprec} bounds the
relative error exactly as specified in functions that support that
granularity (e.g.~\kbd{lfun}), and rounded to the next multiple of 64
(resp.~32) everywhere else.
\misctitle{Warning} Changing \kbd{realbitprecision} or \kbd{realprecision}
in programs is deprecated in favor of \kbd{localbitprec} and
\kbd{localprec}. Think about the \kbd{realprecision} and
\kbd{realbitprecision} defaults as interactive commands for the \kbd{gp}
interpreter, best left out of GP programs. Indeed, the above rules imply that
mixing both constructs yields surprising results:
\bprog
? \p38
? localprec(19); default(realprecision,1000); Pi
%1 = 3.141592653589793239
? \p
realprecision = 1001 significant digits (1000 digits displayed)
@eprog\noindent Indeed, \kbd{realprecision} itself is ignored within
\kbd{localprec} scope, so \kbd{Pi} is computed to a low accuracy. And when
we leave the \kbd{localprec} scope, \kbd{realprecision} only regains precedence,
it is not ``restored'' to the original value.
%\syn{NO}