[R-pkg-devel] check_equal() test fails on ATLAS

Hello all, My package *WeightIt* is failing the CRAN test on ATLAS. The failure is due to a failed *testthat* test comparing two covariance matrices using check_equal()

Re: [R-pkg-devel] Inconsistent functionality of c++ code in MatchIt

I want to thank Bill and everyone that reached out to me individually. It looks like Bill's solution is the right one, as he was able to replicate and fix the problem. I am still a bit confused on why this would occur on some OSs and not others (probably due to different compilers), but I think the

[R-pkg-devel] Inconsistent functionality of c++ code in MatchIt

Hello, I'm the mainter of the package *MatchIt*, which uses *Rcpp* to implement nearest neighbor matching. One way to customize nearest neighbor matching is to add a caliper, which is the largest distance two units can be from each other before they are not allowed to be matched. I've had some use

Re: [R-pkg-devel] Should 'methods' be in Imports?

Thank you both for your responses. Based on Ivan's dig into the comments, it seems there is ambiguity, even by the CRAN team. Still, it looks like it would be preferable to (and would not cause any harm to) include the base packages in DESCRIPTION if they are used at all in a package, whether by ::

Re: [R-pkg-devel] Should 'methods' be in Imports?

Thank you for your input. *broom*, *mlogit*, *twang*, and *Hmisc* are examples of major packages that import functions from *stats*, *utils*, *graphics*, or other base packages but don't include them in the DESCRIPTION. All of my packages (*cobalt*, *WeightIt*, *MatchIt*) do too, and I have never h

[R-pkg-devel] Should 'methods' be in Imports?

Hello developers, I am wondering if base packages whose functions are used in my package need to be present in Imports in my DESCRIPTION. For example, if I use the function abline(), which exists in the *graphics* package, do I need to include *graphics* in Imports? Note I am not asking about whet

[R-pkg-devel] Save and restoring random number seed in a package function

Hello fellow developers, I am attempting to solve the problem of saving the state of the random generator so that the state can be recovered in a future call. Essentially, my function generates random numbers, performs an operation on them (saving the result), and throws them out (saving them woul

Re: [R-pkg-devel] Package manual build problem: ">" not rendered correctly

g me solve this problem. Noah @Rolf We are all flawed in our own ways :) The only dark magic I have ever cast has been getting formula numbers in Microsoft Word. On Fri, Feb 25, 2022 at 4:43 PM Rolf Turner wrote: > On Fri, 25 Feb 2022 12:49:49 -0500 > Noah Greifer wrote: > > >

Re: [R-pkg-devel] [External] Re: What is a "retired"package?

apply() also recently got a 'simplify' argument, which means you request its output be returned as a list, too (i.e., to replace alply). Noah On Tue, Sep 21, 2021 at 12:10 PM Jeff Newmiller wrote: > As you previously quoted: > > > plyr is retired: this means only changes necessary to keep it on

Re: [R-pkg-devel] Suggesting gurobi

Thank you all for your help. I won't set up a repo for gurobi because I don't have the authority to do that. It seems like I should include gurobi in Suggests, even though it cannot be automatically installed from any repository, include instructions for installing it in Description, and just deal

[R-pkg-devel] Suggesting gurobi

AN checks, though. I'm wondering what the best practices are for including gurobi in my package. To be clear, its use is optional and the package can be functional without it, but it greatly enhances performance so I want my users to be able to use it. Thank you! Noah Greifer [[al