[Rd] Converting non-32-bit integers from python to R to use bit64: reticulate

[Martin Maechler]

>>>>> Juan Telleria Ruiz de Aguirre 
>>>>>     on Mon, 3 Jun 2019 06:50:17 +0200 writes:

    > Thank you Martin for giving to know and developing 'Rmpfr' library for
    > unlimited size integers (GNU C GMP) and arbitrary precision floats (GNU C
    > MPFR):

    > https://cran.r-project.org/package=Rmpfr

    > My question is: In the long term (For R3.7.0 or R3.8.0):

    > Does it have sense that CMP substitutes INTSXP, and MPFR substitutes
    > REALSXP code? With this we would achieve that an integer is always an
    > integer, and a numeric double precision float always a numeric double
    > precision float, without sometimes casting underneath.

    > And would the R Community / R Ordinary Members would be willing to help R
    > Core on such implementation (If has sense, and wants to be adopted)?

No, such a change has "no sense" and hence won't be adopted (in
this form):

- INTSXP and REALSXP are part of the C API of R, and are well defined.
  Changing them will almost surely break 100s and by
  dependencies, probably 1000s of existing R packages.

- I'm sure Python and other system do have fixed size "double
  precision" vectors, because that's how you interface with all
  pre-existing computational libraries,
  and I am almost sure that support of arbitrary long integer
  (or double) is via another class/type.

- I know that Julia has adopted these (GMP and MPFR I think)
  types and nicely interfaces them on a relatively "base" level.
  With their nice class hierarchy (and very nice "S4 like" multi-argument
  method dispatch for *all* functions) it can look quite
  seemless for the user to work with these extended classes, but
  they are not all identical to the basic "real"/"double" or "integer" classes.
  
- I'm not the expert here (but there are not so many experts
  ..), but I'm pretty sure that adding new "basic types" in the
  underlying C level seems not at all easy for R.  It would mean a big
  break in all back compatibility -- which is conceivable --
  and *may* also need a big rewrite of much of the R code base
  which seems less conceivable in the mid term (2-3 years; long
  term: > 5 years).


    > Thank you all! :)

You are welcome.

I think we should close this thread here,  unless some real
experts join.

Martin