URGENT or "DO first" :

19) outer() now works  always ? {as rep() now S3 dispatches
    ---> need systematic checks *AND* docu changes!

17b)  see 'Ops' in R/Arith.R  ,  Rmpfr:::.Math.codes,  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 the same as 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

 [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

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 ?


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(): we use builtin zeta(); alternatively, use *exact*
     rationals from 'gmp', using "bigq" (and "bigz") -- and R code from ~/R/Pkgs/copula/R/special-func.R
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  MPFR_RNDN in src/utils.c and others; --> use src/convert.c  R_rnd2MP()
    -- and all the SEXP functions get an additional   SEXP rnd_mode
       argument, the same as   SEXP d2mpfr1() in src/convert.c has already.


27) sapply(), vapply() etc do not work with mpfr --- show workaround
    e.g. from ~/R/MM/Pkg-ex/Rmpfr/Dutang_test_v6.R
	 res.mpfr <- lapply(1:length(n), function(i) binomsum.mpfr.MM(n[i], f, n0, precBits=precBits[i], ...))
	 sapply(res.mpfr, as, "double")


29) Our sum() should use   mpfr_sum() :
   mpfr_sum (mpfr_t ROP, mpfr_ptr const TAB[], unsigned long int N, mpfr_rnd_t RND)

31) Use ./LUP.R  to compute the lu() decomposition of an mpfrMatrix
    ---> use this for determinant() for larger (n >= 4 ?) dimensions!


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.
