[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
Sat Jun 1 18:29:01 CEST 2019
>>>>> Juan Telleria Ruiz de Aguirre
>>>>> on Thu, 30 May 2019 18:46:29 +0200 writes:
>Thank you Gabriel for valuable insights on the 64-bit integers topic.
>In addition, my statement was wrong, as Python3 seems to have unlimited
>(and variable) size integers.
If you are interested in using unlimited size integers, you
could use the CRAN R package 'gmp' which builds on the GMP = GNU
MP = GNU Multi Precision C library.
(and for arbitrary precision "floats", see CRAN pkg 'Rmpfr'
built on package gmp, and both the GNU C libraries GMP and
>Division between Int-32 and Int-64 seems to only happen in Python2.
>El miércoles, 29 de mayo de 2019, Gabriel Becker <gabembecker using gmail.com>
>> Hi Juan,
>> Comments inline.
>> On Wed, May 29, 2019 at 12:48 PM Juan Telleria Ruiz de Aguirre <
>> jtelleria.rproject using gmail.com> wrote:
>>> Dear R Developers,
>>> There is an interesting issue related to "reticulate" R package which
>>> discusses how to convert Python's non-32 bit integers to R, which has had
>>> quite an exhaustive discussion:
>>> Python seems to handle integers differently from R, and is dependant on
>>> system arquitecture: On 32 bit systems uses 32-bit integers, and on 64-bit
>>> systems uses 64-bit integers.
>>> So my question is:
>>> As regards R's C Interface, how costly would it be to convert INTSXP from
>>> 32 bits to 64 bits using C, on 64 bits Systems? Do the benefits surpass
>>> costs? And should such development be handled from within R Core /
>>> Members , or it shall be left to package maintainers?
>> Well, I am not an R-core member, but I can mention a few things:
>> 1. This seems like it would make the results of R code non-reproducible
>> between 32 and 64bit versions of R; at least some code would give different
>> results (at the very least in terms of when integer values overflow to NA,
>> which is documented behavior).
>> 2. Obviously all integer data would take twice as much memory, memory
>> bandwidth, space in caches, etc, even when it doesn't need it.
>> 3. Various places treat data /data pointers coming out of INTSXP and
>> LGLSXP objects the same within the internal R sources (as currently they're
>> both int/int*). Catching and fixing all those wouldn't be impossible, but
>> it would take at least some doing.
>> For me personally 1 seems like a big problem, and 3 makes the conversion
>> more work than it might have seemed initially.
>> As a related side note, as far as I understand what I've heard from R-core
>> members directly, the choice to not have multiple types of integers is
>> intentional and unlikely to change.
>>> Thank you! :)
More information about the R-devel