[R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

Hi, I wrote and maintain the Thresher package. It includes code to do simulations. In the "tests" directory of the package, I do some simple simulations and run the main algorithm, then write out summaries of the results The initial submission of the package to CRAN was delayed because the

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

On 17/05/2018 11:53 AM, Martin Maechler wrote: Kevin Coombes on Thu, 17 May 2018 11:21:23 -0400 writes: > Hi, I wrote and maintain the Thresher package. It includes > code to do simulations. In the "tests" directory of the > package, I do some

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

> Kevin Coombes > on Thu, 17 May 2018 11:21:23 -0400 writes: > Hi, I wrote and maintain the Thresher package. It includes > code to do simulations. In the "tests" directory of the > package, I do some simple simulations and run the main >

Re: [R-pkg-devel] why can't we importFrom 'methods' ?

On 17/05/2018 11:51 AM, Brian G. Peterson wrote: newer versions of R require importFrom for functions from 'stats', 'graphics' and many other packages that used to be assumed to be on the search path and thus available. 'methods' continues to have seemingly different treatment. If you try to

[R-pkg-devel] why can't we importFrom 'methods' ?

newer versions of R require importFrom for functions from 'stats', 'graphics' and many other packages that used to be assumed to be on the search path and thus available. 'methods' continues to have seemingly different treatment. If you try to use importFrom to import a single function (in this

Re: [R-pkg-devel] why can't we importFrom 'methods' ?

On 05/17/2018 11:59 AM, Duncan Murdoch wrote: On 17/05/2018 11:51 AM, Brian G. Peterson wrote: newer versions of R require importFrom for functions from 'stats', 'graphics' and many other packages that used to be assumed to be on the search path and thus available. 'methods' continues to

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

> Duncan Murdoch > on Thu, 17 May 2018 12:13:01 -0400 writes: > On 17/05/2018 11:53 AM, Martin Maechler wrote: >>> Kevin Coombes ... on Thu, 17 >>> May 2018 11:21:23 -0400 writes: >>[..] >> > [3] Should the documentation (man

[R-pkg-devel] how to document method arguments that aren't in the signature

What's the best way to document an S4 method that takes arguments beyond those in the signature? Consider setGeneric("sim", function(simP, dataP, ...) standardGeneric("sim")) setMethod("sim", signature="SimParameters", function(simP, dataP) { lapply(seq(simP@NIter), function(i) do.one(simP,

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

There have been various comments in this thread (by me, and I think Duncan Murdoch) about how you can identify the platform you're running on (some combination of .Platform and/or R.Version()) and use it to write conditional statements so that your tests will only be compared with reference values

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

But why would you want to tie your tests to specific platforms, if mathematically all those results are equivalent? You could compare the orthogonal complements from a full rank matrix (say the identity) to each expected eigenspace. E.g., for the example I gave above, where e2 and e1 gave

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

Yes; I'm pretty sure that it is exactly the repeated eigenvalues that are the issue. The matrices I am using are all nonsingular, and the various algorithms have no problem computing the eigenvalues correctly (up to numerical errors that I can bound and thus account for on tests by rounding

Re: [R-pkg-devel] mvrnorm, eigen, tests, and R CMD check

Yes; but I have been running around all day without time to sit down and try them. The suggestions make sense, and I'm looking forward to implementing them. On Thu, May 17, 2018, 3:55 PM Ben Bolker wrote: > There have been various comments in this thread (by me, and I think >