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}
