similar to: new package 'bit64' - 1000x faster than 'int64' sponsored by Google

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

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

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

I?m in the process of preparing a package for CRAN. The package is called ?exportR? and since it really just consists of one function, I found it natural to call it ?exportR? too. The function returns a function that does the actual job, but it is set up to work in different ways, depending on the arguments given to its creator. In short: library( exportR ) exporter <- exportR( the, arguments

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

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

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

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

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

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: https://github.com/rstudio/reticulate/issues/323 Python seems to handle integers differently from R, and is dependant on the system arquitecture: On 32 bit systems uses 32-bit integers,

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. Here is related CPython Code: https://github.com/python/cpython/blob/master/Objects/longobject.c Division between Int-32 and Int-64 seems to only happen in Python2. Best, Juan El mi?rcoles, 29 de mayo de 2019, Gabriel

An upcoming patch to add callbacks for aio completion notification wants to expose Int64 as a callback parameter. It's time to wire that up. --- generator/generator | 25 +++++++++++++++---------- 1 file changed, 15 insertions(+), 10 deletions(-) diff --git a/generator/generator b/generator/generator index 45a030f..c5988e2 100755 --- a/generator/generator +++ b/generator/generator @@ -3508,7

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 Mon, Nov 20, 2017 at 1:07 PM, James Zern <jzern at google.com> wrote: > Just an attempt to avoid overflows with an explicit check, I don't know if > there's a better way to identify corrupt input here. > > James Zern (2): > op_pcm_seek: fix int64 overflow > op_fetch_and_process_page: fix int64 overflow > > src/opusfile.c | 11 +++++++++-- > 1 file

This patch simplifies XMM -> int64 conversion in fixed_intrin_sse2.c and fixed_intrin_ssse3.c -------------- next part -------------- A non-text attachment was scrubbed... Name: fixed_sse.zip Type: application/zip Size: 778 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140813/49f18196/attachment.zip

I happened on to a website from Google that says there was a Digium/Google sponsored project to add certificates and TLS and TCP (as opposed to just UDP) to Asterisk. Does anyone know anything about this as it indicates that it works in the current asterisk (since like August of 2005). The web site is: http://savannah.nongnu.org/projects/asterisk-tcp Go to the News Page and it indicates TLS