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
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
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"))
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
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:
| >
|
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
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
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(...)
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
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()
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]
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
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
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
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
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
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.
|
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
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
19 matches
Mail list logo
