From m@ech|er @end|ng |rom @t@t@m@th@ethz@ch  Tue Jun  4 18:08:27 2019
From: m@ech|er @end|ng |rom @t@t@m@th@ethz@ch (Martin Maechler)
Date: Tue, 4 Jun 2019 18:08:27 +0200
Subject: [Rd] 
 Converting non-32-bit integers from python to R to use bit64:
 reticulate
In-Reply-To: <CAJXDcw1oP51CdTqRLvOCNGPze2mS3Y+df3SUfO=bwsHRb3nzfg@mail.gmail.com>
References: <CAJXDcw3jQd2B+hvfXuUUeczx=mmtw0MA_Udaesd-UgM+spyGJw@mail.gmail.com>
 <CAD4oTHH_ixXYEk1OEuFq_yJf83sDYmShbZ1nPGFovRvy-XZPnw@mail.gmail.com>
 <CAJXDcw1V=2Z0BM31Ovc5SfiUEotuHoQRqWWi5z-8UfRg2qkM5w@mail.gmail.com>
 <23794.42957.74307.509821@stat.math.ethz.ch>
 <CAJXDcw1oP51CdTqRLvOCNGPze2mS3Y+df3SUfO=bwsHRb3nzfg@mail.gmail.com>
Message-ID: <23798.38779.375414.460468@stat.math.ethz.ch>

>>>>> 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



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