[Rd] Converting non-32-bit integers from python to R to use bit64: reticulate
m@ech|er @end|ng |rom @t@t@m@th@ethz@ch
Tue Jun 4 18:08:27 CEST 2019
>>>>> 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
> 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
- 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
More information about the R-devel