similar to: 64-bit integer type warning on windows

Dear useRs, We are happy to announce a new version of the randtoolbox* package (version 1.09) on CRAN. The package is dedicated to Random Number Generation and in a less exhaustive way to RNG tests. The package is source-controlled at r-forge as part of the Rmetrics project http://r-forge.r-project.org/projects/rmetrics/ . We invite you to take a look at the NEWS section to know the

Dear useRs, We are happy to announce a new version of the randtoolbox* package (version 1.09) on CRAN. The package is dedicated to Random Number Generation and in a less exhaustive way to RNG tests. The package is source-controlled at r-forge as part of the Rmetrics project http://r-forge.r-project.org/projects/rmetrics/ . We invite you to take a look at the NEWS section to know the

Hi all, I'm currently implementing quasi random generation (torus) on R (package randtoolbox available on CRAN). Even if it is not a great idea, I decided to use the machine time to initiate the seed. So when the seed is not specified by the user, the pkg uses the time machine time. Hence the following R code should produce different uniform variates : > for(i in

On Mon, Sep 14, 2015 at 8:49 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: > I tested this hypothesis by replacing '__GNUC__ <= 4' with '__GNUC__ > <= 5' and rebuilding R, but this introduces a whole lot of problems > that were not there before. In particular R crashes when using the > graphics device, which it did not without this fix. I found

Hi, I'm currently R porting SF Mersenne Twister algorithm of Matsumoto and Saito. To get the full power of their code, I want to use their fonction fill_array32 which need aligned memory. That is to say I need to use the C function memalign on windows, posix_memalign on linux and classic malloc on Mac OS. In 'writing R extenstion', they recommand to use R_alloc function to

Hi, I'm currently R porting SF Mersenne Twister algorithm of Matsumoto and Saito. To get the full power of their code, I want to use their fonction fill_array32 which need aligned memory. That is to say I need to use the C function memalign on windows, posix_memalign on linux and classic malloc on Mac OS. In 'writing R extenstion', they recommand to use R_alloc function to

Dear list, I?m trying to register Fortran routines in randtoolbox (in srt/init.c file), see https://r-forge.r-project.org/scm/viewvc.php/pkg/randtoolbox/src/init.c?view=markup&root=rmetrics. Reading https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Registering-native-routines and looking at what is done in stats package, I first thought that the following code will do the job:

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

Hello r users, I have to deal with int8 data with R. AFAIK R does only handle int4 with `as.integer` function [1]. I wonder: 1. what is the better approach to handle int8 ? `as.character` ? `as.numeric` ? 2. is there any plan to handle int8 in the future ? As you might know, int4 is to small to deal with earth population right now. Thanks for you ideas, int8 eg: human_id

> On 9 May 2017, at 13:44, Christophe Dutang <dutangc at gmail.com> wrote: > > Dear list, > > I?m trying to register Fortran routines in randtoolbox (in srt/init.c file), see https://r-forge.r-project.org/scm/viewvc.php/pkg/randtoolbox/src/init.c?view=markup&root=rmetrics. > > Reading

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

On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help. I have been looking into this a bit over

On 2015-01-08 02:31, Duncan Murdoch wrote: > On 07/01/2015 5:20 PM, Jeroen Ooms wrote: >> On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>> >>> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now

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

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

On 07/01/2015 5:20 PM, Jeroen Ooms wrote: > On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> >> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > On 09/01/2015 10:56 AM, Henric Winell wrote: >> On 2015-01-08 02:31, Duncan Murdoch wrote: >> >>> On 07/01/2015 5:20 PM, Jeroen Ooms wrote: >>>> On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >>>>>

Thanks for your email. I try to change the name in lowercase but it conflicts with a C implementation also named halton. So I rename the C function halton2() and sobol2() while the Fortran function are HALTON() and SOBOL() (I also try lower case in the Fortran code). Unfortunately, it does not help since I get init.c:97:25: error: use of undeclared identifier 'halton_'; did you mean

Buenas chicos, Estoy intentando importar el csv que adjunto y que tiene la siguietne forma: "a";"b" 11092740;0 8978056137;0 Usando la funcion fread. Necesito usar la función fread por velocidad (lo que envio es un ejemplo simplificado pero que replica el error). El problema es que al importar los datos, usando: datos<-fread(datos.csv,sep=";") el campo a no lo