Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread وليد خلف معوض المطيرى
Hi all, I think what I�ve done is something different. Inside the Fortran subroutine, I have a subroutine for setting the seed value of the RNG of GNU Fortran which I think it is not related to the R RNG like the one below: subroutine initrandomseedsinr(temp) implicit none integer

Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread Ralf Stubner
On Fri, Jan 17, 2020 at 2:56 PM ‫وليد خلف معوض المطيرى‬‎ wrote:‬ > This might be because the RNG method used in random_number function is > different between the used version GCC 6 or less and the new ones GCC 8 or > greater. This is quite likely correct. The current gfortran docs [1] list

Re: [R-pkg-devel] warnings by 3rd party headers

2020-01-17 Thread Iñaki Ucar
On Fri, 17 Jan 2020 at 20:42, Guido Kraemer wrote: > > Thanks, just to drive this a bit further: > > What if the headers then start producing some ugly compile warnings? Do > I have to fix these, too? How ugly? You can ignore "variable set but not used"-kind of stuff, but if things turn ugly

Re: [R-pkg-devel] warnings by 3rd party headers

2020-01-17 Thread Guido Kraemer
Thanks, just to drive this a bit further: What if the headers then start producing some ugly compile warnings? Do I have to fix these, too? On 1/16/20 5:12 PM, Dirk Eddelbuettel wrote: On 16 January 2020 at 17:06, Iñaki Ucar wrote: | On Thu, 16 Jan 2020 at 16:58, Guido Kraemer wrote: | > |

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Smith, Brian J
I spoke too soon. dotsMethods will not work for me since it does not allow for mixing of the ellipsis with other formal arguments. For example, the following will not work if argument 'data' is not a formula; e.g. a data frame. setGeneric("foo2", function(...) standardGeneric("foo2"))

Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread Avraham Adler
If I understand what you're doing, your Fortran seed knows nothing about the R state. Is it possible to switch to using the R random number generators? Or can you at least use the probability integral transform to generate uniform [0, 1] via R and then convert those to observations in Fortran

Re: [R-pkg-devel] Proper way to ask a user to set permanent variables?

2020-01-17 Thread Rainer M Krug
Hi Dirk, The package-local environment is definitely a good approach (I use it myself an a few packages). And the options() are nice as they represent a standardised interface in R (Note to myself: I should use these more in my packages). But unless I am missing something, these are not

Re: [R-pkg-devel] Proper way to ask a user to set permanent variables?

2020-01-17 Thread Zhian Kamvar
Options are not persistent between sessions unless the user wants them to be. You can have users set the options in their .Rprofile either in the working directory of the project or their home directory. This is the method that the {usethis} package has for storing default names. The only downside

Re: [R-pkg-devel] Proper way to ask a user to set permanent variables?

2020-01-17 Thread Dirk Eddelbuettel
On 17 January 2020 at 09:49, Zhian Kamvar wrote: | Options are not persistent between sessions unless the user wants them to | be. You can have users set the options in their .Rprofile either in the | working directory of the project or their home directory. This is the Yes, precisely. |

[R-pkg-devel] For reproducibility issue

2020-01-17 Thread وليد خلف معوض المطيرى
Hi, I am maintaining the EpiILMCT package in CRAN that has been removed recently because of the non-producibility issue. My package passes all the tests without warnings and errors. The issue comes from the tests examples of two functions that are based on Fortran subroutines (comparing the

Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread Ivan Krylov
On Fri, 17 Jan 2020 13:55:39 + وليد خلف معوض المطيرى wrote: > So, does anyone have an idea of how to solve this issue. "Writing R Extensions", 1.6. Writing portable packages: >> Compiled code should not call the system random number generators >> such as rand, drand48 and random, but

[R-pkg-devel] S3 generic/method consistency warning for formula method

2020-01-17 Thread Smith, Brian J
Hello all, I am getting an R CMD check warning about S3 consistency for a formula method of a generic function that dispatches on the ellipsis argument. The formula method seems to function properly when called, and methods for other types tried do not trigger the warning. Below is an

Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread Jeff Newmiller
As an existing package I suspect that it already calls the R RNG, but the default RNG changed [1] so you need to call RNGkind(sample.kind = "Rounding") before calling set.seed in your test code to compare with old results. [1]

Re: [R-pkg-devel] For reproducibility issue

2020-01-17 Thread Avraham Adler
Hi. If it helps, I call the R RNG from Fortran in my Delaporte package [1], also using iso_c_bindings. Specifically, I have the following C code [2]: void F77_SUB(unifrnd) (int *n, double *x){ GetRNGstate(); for (int i = 0; i < *n; ++i){ *(x + i) = unif_rand(); } PutRNGstate(); } and call it in

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Smith, Brian J
Thanks Duncan. I was surprised too when first realizing this was possible. I believe the reason it works is that UseMethod dispatches on the first supplied argument by default. So, really the dispatch is on the first element of the ellipsis. The 'c' function works like this, albeit as a

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Joris Meys
Hi Brian, I get what you want to do, but S3 isn't suited for that at all. If all elements in ... have to be the same class, you can use S4 (see ?dotsMethods). If not, then using S3 makes even less sense. Take following example: x <- list() y <- c(1,2) foo(x,y) will dispatch to foo.list()

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Joris Meys
umfff. foo(y,x) will dispatch to foo.numeric() obviously __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Smith, Brian J
Thanks for the tip about dotsMethods. I am mainly working with S4 objects in my package, so that approach would fit well. The following S4 method seems to work and pass R CMD checks. setGeneric("foo2", function(...) standardGeneric("foo2")) setMethod("foo2", "formula", function(...)

Re: [R-pkg-devel] [External] Re: S3 generic/method consistency warning for formula method

2020-01-17 Thread Smith, Brian J
That's an interesting solution too. -Original Message- From: Duncan Murdoch Sent: Friday, January 17, 2020 11:17 AM To: Smith, Brian J ; r-package-devel@r-project.org Subject: Re: [External] Re: [R-pkg-devel] S3 generic/method consistency warning for formula method On 17/01/2020 10:59