URGENT or "DO first" :

xx) sumBinomMpfr()  accept  f.x

17b)  see 'Ops' in R/Arith.R  and
     design a "test all Ops" with all combinations of "mpfr", "numeric","logical"
     (and possibly more).

21) What's the exponent range -- can we change it? - --> Need R interface to

   — Function: int mpfr_set_emin (mpfr_exp_t exp)
   — Function: int mpfr_set_emax (mpfr_exp_t exp)

       Set the smallest and largest exponents allowed for a floating-point variable. Return a non-zero value when exp is not in the range accepted by the implementation (in that case the smallest or largest exponent is not changed), and zero otherwise. If the user changes the exponent range, it is her/his responsibility to check that all current floating-point variables are in the new allowed range (for example using mpfr_check_range), otherwise the subsequent behavior will be undefined, in the sense of the ISO C standard.

   — Function: mpfr_exp_t mpfr_get_emin_min (void)
   — Function: mpfr_exp_t mpfr_get_emin_max (void)
   — Function: mpfr_exp_t mpfr_get_emax_min (void)
   — Function: mpfr_exp_t mpfr_get_emax_max (void)

       Return the minimum and maximum of the exponents allowed for mpfr_set_emin and mpfr_set_emax respectively. These values are implementation dependent, thus a program using mpfr_set_emax(mpfr_get_emax_max()) or mpfr_set_emin(mpfr_get_emin_min()) may not be portable.

 ---> model this analogous to   SEXP R_mpfr_get_default_prec(void)
      in src/utils.c
      	 ~~~~~~~~~~~





---------------------------- compare to ./Done ------------------------

2)
 - Now have working  "mpfrMatrix", dim(.) <- ..; t(), %*%, crossprod()...

 -  <mpfr> %*% <mpfr>    should work like with numeric vectors
 -  <mpfr> %*% t(<mpfr>)  ditto

  Note that matrix multiplication seems too slow --> ./Savicky-matrix-mult_tst.R

 -  <mpfr>[i] & <mpfrMatrix>[i]  work
    but   <mpfrMatrix> [i,j]  not yet

 -->  want things to work like
          which(<mpfrMatrix> == ., arr.ind = TRUE)  - ok
          outer(....)                               - not yet

 [No longer sure if this is true :]
 For this, we must ensure that the methods are used, instead of the
 .Primitive  base functions :

 One way: --> see ~/R/MM/NUMERICS/bessel-large-x.R
                  --------------------------------

  ## really interesting is  bI(x., nu)  {for "mpfr" argument}:
  ## it uses outer(), but that needs to dispatch on, e.g. "^",
  ## i.e., not only look at "base"
  environment(outer) <- as.environment("package:Rmpfr")
  environment(dim) <- as.environment("package:Rmpfr")
  environment(dimnames) <- as.environment("package:Rmpfr")
  environment(`dim<-`) <- as.environment("package:Rmpfr")
  environment(`dimnames<-`) <- as.environment("package:Rmpfr")
  environment(which) <- as.environment("package:Rmpfr")

5) I'd like seq() methods, but that seems currently impossible because of
   a "design infelicity" in base::seq.default  --- ???? E-mail to R-core ??
   --> R/mpfr.R

6) It is "wrong" that the class "Mnumber" also extends "character", "list";
   but it's not clear we can find better definitions, see R/AllClasses.R

7) Add tests for hypot() & atan2() to tests/special-fun-ex.R

8) round(x, .) & signif(x, .) currently return "mpfr" numbers of the same precision.
   That *looks* ugly.
   Potentially add a swith 'keepPrec = FALSE' -- i.e. by default *reduce*
   precision to "match" 'digits' argument.

9) median(mpfr(1:4, 60)) now fails, but mean(.) and quantile() both work.
   ------ The infelicity could be seen in the way namespaces work :
   median.default() calls the correct sort() on "mpfr", but calls the *wrong*
   base::mean() instead of mean() {which is S4 by then} ....
   all would be fine if  base::mean() was *already* S4 generic ....
   of course I could replace base::mean() by the S4 generic on
   package-load time, but would prefer a cleaner solution.
   ---> talk to Luke and John (and ??) about that

11) format() method for "mpfrArray" (and hence "mpfrMatrix") which nicely
    and correctly *jointly* formats and aligns  columns !
    drop0trailing is not really sensible there

13) implement the  NOT_YET  in src/Ops.c

16) psigamma(x, n)  {and  digamma(), trigamma() aliases}
    --> experiments in ~/R/MM/Pkg-ex/Rmpfr/psigamma.R )
    Note that since, MPFR 3.0.0, there is a digamma(); .. which we now interface to

18) ifelse()  fails ... maybe I should mask it
             {or "fix it" via assign*() in base ?? -- they will love that!}
    or provide ifelse2() -- a fast simplified version ?

19) outer() fails too, (similarly I think)

22) *do* test rank(), sort(), order() : we claim they work in man/mpfr-class.Rd
    quantile() should work from R 2.15.1 (June 2012) on       ~~~~~~~~~~~~~~~~~

24)  Bernoulli() should really happen in 'gmp', using "bigq" (and "bigz")
25) mpfr(<mpfr>, ...) should work: return argument unchanged *if* precision
    and rounding mode are ok; otherwise use roundMpfr() *BUT* that needs an
    additional rnd.mode  argument -- as mpfr
26) (?) Revert the decision to *not* care about rounding mode in Ops/function,
    and rather expose that as in mpfr(), e.g., in R/Math.R  roundMpfr
    -- see  GMP_RNDN in src/utils.c and others; see also src/convert.c  R_rnd2GMP()

27)
28)

50) For *complex* arithmetic, build interface to the  "MPC" library
   ---> http://www.multiprecision.org/mpc -- which is LGPL and itself
   builds on MPFR and GMP.
   Ubuntu now has 'libmpc-dev' (!)  {but there's no '*-doc' package yet;
   	      	  	       	     on nb-mm, I've installed from source
				     --> Info comes along}
  One idea: Since the names are so much in parallel, try
      to take each src/*.c file and mechanically  s/mpfr/mpc/  producing a
      mpc version of that;
      then "the same" for the R interface code.
