[R] : Ramanujan and the accuracy of floating point computations - using Rmpfr in R

[Martin Maechler]

>>>>> "P" == ProfJCNash  <profjcnash at gmail.com>
>>>>>     on Sat, 4 Jul 2015 21:42:27 -0400 writes:

    P> n163 <- mpfr(163, 500)

    P> is how I set up the number.

Yes, and you have needed to specify the desired precision.

As author and maintainer of Rmpfr, let me give my summary of this overly
long thread (with many wrong statements before finally RK give
the "obvious" answer):

1) Rmpfr is about high (or low, for didactical reasons, see Rich
   Heiberger's talk at 'useR! 2015') precision __numerical__ computations.
   This is what the GNU MPFR library is about, and Rmpfr wants
   to be a smart and R-like {e.g., automatic coercions wherever they
   make sense} R interface to MPFR.

2) If you use Rmpfr, you as user should decide about the desired accuracy
   of your "inputs".
   I think it would be a very bad idea to redefine 'pi' (in
   Rmpfr) to be Const("pi", 120).

   R-like also means that in a computation   a * b   the
   properties of a and b determine the result, and hence if  a <- pi
   then we know that pi is a double precision number with 53-bit
   mantissa.


    p> On 15-07-04 05:10 PM, Ravi Varadhan wrote:
    >>> What about numeric constants, like `163'?

well, if you _combine_ them with an mpfr() number, they are used
in their precision.  An integer like 163 is exact of course; but
pi (another numeric constant) is 53-bit as mentioned above, 
*and*     sqrt(163)  is ("R-like") a double precision number
computed by R's internal double precision arithmetic.

My summary:

--------------------------------------------------------------------
    1. Rmpfr behaves entirely correctly and as documented 
       (in all the examples given here).

    2. The idea of substituting expressions containing pi with
       something like Const("pi", 120) is not a good one.  (*)
--------------------------------------------------------------------


*) One could think of adding a new class, say "symbolicNumber"
   or rather "numericExpression" which in arithmetic would
   try to behave correctly, namely find out what precision all
   the other components in "the arithmetic" have and make sure
   all parts of the 'numericExpression' are coerced to
   'mpfr' with the correct precision, and only then start
   evaluating "the arithmetic".

   But that *does* look like implementation of
   Maple/Mathematica/... in R  and that seems silly; rather R
   should interface to Free (as in "speech") aka "open source"
   symbolic math packages such as Pari, macysma, ..

Martin Maechler
ETH Zurich