similar to: Using long long types in C++

Dear R Developers, I would like to pick up back again the issue of 64 bits integers with R: http://r.789695.n4.nabble.com/Re-R-support-for-64-bit-integers-td2320024.html *** CURRENT SITUATION *** At the moment, as regards integers, all the following are the same type: * length of an R vector * R integer type * C int type (Fixed at 32 bits: In practice) * Fortran INTEGER type (Fixed at 32

Dear R-Core team, Dear Rcpp team and other package teams, Dear R users, The new package 'bit64' is available on CRAN for beta-testing and code-reviewing. Package 'bit64' provides fast serializable S3 atomic 64bit (signed) integers that can be used in vectors, matrices, arrays and data.frames. Methods are available for coercion from and to logicals, integers, doubles,

Dear R-Core team, Dear Rcpp team and other package teams, Dear R users, The new package 'bit64' is available on CRAN for beta-testing and code-reviewing. Package 'bit64' provides fast serializable S3 atomic 64bit (signed) integers that can be used in vectors, matrices, arrays and data.frames. Methods are available for coercion from and to logicals, integers, doubles,

Dear R community, The new version of package 'bit64' - which extends R with fast 64-bit integers - now has fast (single-threaded) implementations of the most important univariate algorithmic operations (those based on hashing and sorting). Package 'bit64' now has methods for 'match', '%in%', 'duplicated', 'unique', 'table',

Dear R community, The new version of package 'bit64' - which extends R with fast 64-bit integers - now has fast (single-threaded) implementations of the most important univariate algorithmic operations (those based on hashing and sorting). Package 'bit64' now has methods for 'match', '%in%', 'duplicated', 'unique', 'table',

Some of you may recall that I have been working on building a box to convert H323 to SIP. After a significant amount of outside help and slicing and dicing of the ohh323 code to get it to compile on AMD64 we finally got it working. Now we are working on improving the performance. This box takes H323 from one device and converts to SIP and spits it back out to another device. The codec is g729 but

How many unique idenfiiers do you have? If they are large (in terms of bytes) but you don't have that many of them (eg the total possible number you'll ever have is < INT_MAX), you could store them as factors. You get the speed of integers but the labeling of full "precision" strings. Factors are fast for joins. ~G On Fri, Jan 20, 2017 at 9:47 AM, Nicolas Paris

Hi, I do have < INT_MAX. This looks attractive but since they are unique identifiers, storing them as factor will be likely to be counter-productive. (a string version + an int32 for each) I was looking to https://cran.r-project.org/web/packages/csvread/index.html This looks like a good feet for my needs. Any chances such an external package for int64 would be integrated in core ? Le 20

To summarise this thread, there are basically three ways of handling int64 in R: * coerce to character * coerce to double * store in double There is no ideal solution, and each have pros and cons that I've attempted to summarise below. ## Coerce to character This is the easiest approach if the data is used as identifiers. It will have some performance drawbacks when loading and will

Well I definitely cannot use them as numeric because join is the main reason of those identifiers. About int64 and bit64 packages, it's not a solution, because I am releasing a dataset for external users. I cannot ask them to install a package in order to exploit them. I have to be very carefull when releasing the data. If a user just use read.csv functions, they by default cast the

Hi guys, i'm not going to have time to work on this for a month or two, so i figured i'd post it. This patch 1. reworks the andersen's implementation to support field sensitivity (though field-sensitive constraints are not generated directly yet), and uses it to do indirect function call support. 2. Rewrites the solver to be state of the art in terms of speed. kimwitu++ used to take

Gracias Carlos, Me lo ha solucionado, pero.. ¿Por que es necesario instlara ese paquete? Un saludo Jesús ________________________________ De: Carlos Ortega <cof en qualityexcellence.es> Enviado: viernes, 6 de octubre de 2017 14:51 Para: Jesús Para Fernández Cc: r-help-es en r-project.org Asunto: Re: [R-es] Importando mal los datos Instala el paquete "bit64".... Saludos, Carlos

Has anyone here done this? I got it compiled just fine but when I make a call I do not get any audio going either way. The * box is not behind any sort of firewall or nat. My H323 client (gnomemeeting) is behind NAT but I have it set up properly to work through NAT and it will talk correctly with my other regular x86 box running H323. One odd thing I note is that when looking at the UDP traffic

The lack of 64 bit integer support causes lots of problems when dealing with certain types of data where the loss of precision from coercing to 53 bits with double is unacceptable. Two packages were developed to deal with this: int64 and bit64. You may need to find archival versions of these packages if they've fallen off cran. Murray (mobile phone) On Jan 20, 2017 7:20 AM, "Gabriel

2^53 == 2^53+1 TRUE Which makes joining or grouping data sets with 64 bit identifiers problematic. Murray (mobile) On Jan 20, 2017 9:15 AM, "Nicolas Paris" <nicolas.paris at aphp.fr> wrote: Le 20 janv. 2017 ? 18h09, Murray Stokely ?crivait : > The lack of 64 bit integer support causes lots of problems when dealing with > certain types of data where the loss of precision

On 15 August 2018 at 20:32, Benjamin Tyner wrote: | Thanks for the replies and for confirming my suspicion. | | Interestingly, src/include/S.h uses a trick: | | ?? #define longint int | | and so does the nlme package (within src/init.c). As Bill Dunlap already told you, this is a) ancient and b) was concerned with the int as 16 bit to 32 bit transition period. Ie a long time ago. Old C

On 08/16/2018 05:12 AM, Dirk Eddelbuettel wrote: > > On 15 August 2018 at 20:32, Benjamin Tyner wrote: > | Thanks for the replies and for confirming my suspicion. > | > | Interestingly, src/include/S.h uses a trick: > | > | ?? #define longint int > | > | and so does the nlme package (within src/init.c). > > As Bill Dunlap already told you, this is a) ancient and

Entendido... El otro dia lei un artículo sobre el efecto 2031 que versaba justo sobre eso.... Una duda mas. En la columna ID hay alguna fila que esta mal metida y tiene un caracter o algo que esta hacinedo que toda esa columna me la importe como un factor y no como un numero. ¿Como detecto esas filas que me están jo...? Gracias Carlos!!! ________________________________ De: Carlos Ortega <cof

Dear list, During the last two months, I spent a lot of time trying to remove the following warnings of my package randtoolbox: congruRand.c:180:3: warning: ISO C does not support the 'I64' ms_scanf length modifier [-Wformat=] sscanf(params[0], "%" PRIu64 "\n", &inp_mod); Please see

Hi Juan, Comments inline. On Wed, May 29, 2019 at 12:48 PM Juan Telleria Ruiz de Aguirre < jtelleria.rproject at 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: > >