[R-pkg-devel] Suggesting gurobi

[Noah Greifer]

Hello,

I have been working on adding an option for my users to use integer
programming (a method of optimization) to enhance the results of a function
in my package. There are several R packages on CRAN that perform integer
programming, including Rglpk and Rsymphony. However, there is a commercial
solver called Gurobi that dramatically outperforms all open-source solvers,
and it comes with an R interface through the gurobi package. I want to
allow my users to use Gurobi to perform the package actions.

A potential issue is that the gurobi package is not on CRAN; it comes with
an installation of the Gurobi software, which requires a license. I am not
sure how to add gurobi to my Description file to satisfy CRAN's
requirements. In CMD CHECK, I get the warning that the package is not
available for checking. However, I have noticed some other packages do use
gurobi just as I want to (i.e., as an option), such as CVXR
<https://cran.r-project.org/package=CVXR> and designmatch
<https://cran.r-project.org/package=designmatch>, which put gurobi in
Enhances (though I would have thought it would belong in Suggests). It
seems that neither of these packages passes the CRAN 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

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Suggesting gurobi

[Noah Greifer]

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 with the fact that cmd check will always flag it as a problem. It does
seem more convenient to just put it in Enhances so it is not flagged on a
check since it is not used in any examples and the code that uses its
functions has alternative options.

Noah

On Mon, Jun 7, 2021 at 12:30 PM Uwe Ligges 
wrote:

>
>
> On 05.06.2021 01:47, Dirk Eddelbuettel wrote:
> >
> > On 4 June 2021 at 16:21, Balasubramanian Narasimhan wrote:
> > | Suggests" would trigger an attempt to install gurobi, which is not on
> CRAN.
> >
> > To my understanding that is not the case. It would only do so if and when
> > install.packages() is asked to also install packages in Suggests:. And
> point
> > of Suggests: is that that is not automagic.
> >
> > I actually Suggests, together with Additional_Repositories: (for which
> Noah
> > may have to set the repo up, I have not checked if gurobi has one) may
> be the
> > correct call.
>
> That would indeed be ideal. As far as I know there is not CRAN-like repo
> with gurobi. Following the CRAN policies you can exolain in the
> Description field of the DESCRIPTION file how to get that package to
> your users.
>
> Best,
> Uwe Ligges
>
> > Dirk
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 CRAN
> will be made.
>
> That excludes bugfixes related to any specific use cases it is not
> currently capable of handling. In other words, if it doesn't handle the
> data you pass along to it from your users, or there turns out to be a
> security problem (I agree, not likely, but remember these agencies don't
> shade things by "likely") then the plyr maintainers aren't promising to fix
> it. Take it "as-is". This is exactly what this "agency" you are being
> hassled by is concerned about... not the label applied to that status.
>
> On September 21, 2021 8:50:32 AM PDT, "Lenth, Russell V" <
> russell-le...@uiowa.edu> wrote:
> >... "I am not fixing this hot mess"??? To the contrary, the README
> contains a clearly expressed intention to maintain plyr to keep in on CRAN.
> >
> >RL
> >
> >-Original Message-
> >From: Jeff Newmiller 
> >Sent: Tuesday, September 21, 2021 10:36 AM
> >To: r-package-devel@r-project.org; Lenth, Russell V <
> russell-le...@uiowa.edu>; r-package-devel@r-project.org
> >Subject: [External] Re: [R-pkg-devel] What is a "retired"package?
> >
> >There is nothing official about that term. However, the meaning as
> intended by the package authors seems pretty clear to me, and if some
> organization decides not to allow software that is not being maintained to
> be relied upon then that is their decision. I don't think slapping a
> different label on "I am not fixing this hot mess" is going to change that
> organization's stance, and expecting the author to play that game is
> unreasonable.
> >
> >Welcome to the downside of package interdependencies. I highly recommend
> that you migrate away from plyr, either by absorbing the key functions you
> need from it or by relying on different packages.
> >
>
> --
> Sent from my phone. Please excuse my brevity.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

Thank you for the help! I found "TinyTeX" which according to its developer
is a lightweight version of TeX Live for use by R users. I thought I had
installed it previously, but maybe not. After doing so, I was able to
render the manual correctly. Thank you for taking a look and helping 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:
>
>
> 
>
> > I know very little about Latex (I don't use it for my writing).
>
> 
>
> IMHO that is a flaw in your character. :-)
>
> cheers,
>
> Rolf Turner
>
> --
> Honorary Research Fellow
> Department of Statistics
> University of Auckland
> Phone: +64-9-373-7599 ext. 88276
>
>

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 would require too much
memory). A second function is meant to take the output of the first
function, generate the same random numbers, and perform a different
operation on them.

This is exactly what happens in the *boot* package: the boot() function
saves the random seed (extracted from .Random.Seed), and the boot.array()
function extracts the saved seed from the boot() output, sets the seed to
that value, re-generates the same set of random numbers, and then
re-sets the seed to what it was before boot.array() was called. This has
the following benefits: 1) it allows the same random numbers to be drawn;
2) the random numbers don't need to be saved, which is good because they
would take up a lot of memory and boot.array() is an optional function (it
is used in boot.ci() with type = "bca" for those curious); and 3) the seed
carries on from where it left off before boot.array() was called instead of
being set to what it was after boot() was called.

This is implemented in boot in the following way (code abbreviated):

boot <- function(...) {
  seed <- .Random.Seed
  #Random numbers generated
  out <- list(seed = seed
  #Other stuff is in this list
  )
  out
}

boot.array <- function(boot.out) {
  #Save current random seed in `temp`
  if (exists(".Random.seed", envir = .GlobalEnv, inherits = FALSE))
temp <- get(".Random.seed", envir = .GlobalEnv, inherits = FALSE)
  else temp <- NULL

  #Assign saved seed from boot.out
  assign(".Random.seed", boot.out$seed, envir = .GlobalEnv)

  #Generate same random numbers from boot() call

  #Restore random seed to what it was before boot.array() call
  if (!is.null(temp))
assign(".Random.seed", temp, envir = .GlobalEnv)
  else rm(.Random.seed, pos = 1)
}

This seems to work as intended. However, this violates the CRAN policy of
changing the global environment. When I used this exact code in a package I
submitted, the package was rejected for it. The message I received was

> Please do not modify the .GlobalEnv (e.g.: by changing the .Random.seed
> which is part of the global environment). This is not allowed by the CRAN
> policies.


I'm curious what you think the best course of action might be, and what the
current policy means for the *boot* package. Thanks for your help.

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 whether I need to
import all or any function from the *graphics* package, that is, assume I
am using graphics::abline(), etc. I am solely asking about the DESCRIPTION
file, not the Namespace.

I ask because there seems to be some ambiguity about this. I received a
pull request from someone adding *methods* to my Imports after noticing I
didn't declare it when using a function from *methods* (accessed in my
package using ::). Looking on StackOverflow, there seems to be confusion
about this. The most relevant question I could find was this one
. The question was marked as
a duplicate despite the linked duplicate being separate from it (i.e.,
asking about the Namespace, not the DESCRIPTION). Similarly, the answer to
the question does not address the question, again referring to the
Namespace and making an irrelevant distinction between Depends and Imports.
Some of the comments reference a CRAN policy, and yet that policy does not
seem to be implemented since many packages (including all of mine) omit the
base packages from the DESCRIPTION.

So, is it optional to include these packages in the DESCRIPTION? I see some
packages do so and some don't. Is including these packages filling the
DESCRIPTION with unnecessary dependencies that are automatically satisfied,
or is it being helpfully explicit about the packages your package relies
on? Thanks.

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 had a message from CRAN about it. (None of these are
specifically about *methods*, but as a base package I assume it should work
the same as these others.)

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 ::
or imported from in the Namespace. I'll update my packages accordingly.

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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
users complain recently that the caliper is not working for them, i.e.,
even after specifying a caliper, units are being matched who are
farther apart then the caliper width. I have been unable to replicate this
problem on my Mac; the caliper always works as intended.

One user noted that even when using the same package version, the
performance varied across two machines: one obeyed the caliper and one
didn't. I thought this might be related to the version of R installed, as
for some users updating R fixed the issue, but for others it didn't. I'm
kind of at a loss.

I have a suspicion that the problem is related to the function abs() in the
C++ functions find_right() and find_left() that I wrote to perform the
matching, which are in nn_match_vec.cpp
.
I have had problems with abs() before (seemingly related to a namespace
conflict between std and Rcpp). In this case, abs() is used in the
following way:

if (abs(distance[ii] - distance[k]) > caliper_dist) {
//if closest is outside caliper, break; none can be found
break;
 }

Here, distance is a NumericVector, and ii and k are ints. My expectation is
that this would dispatch to std::abs() with a double as its input. It's
possible something is going wrong there. I'm wondering if this has to do
with recent changes to R's C++ engine or compilers.

If you want to run code to test whether the caliper is working correctly on
your machine, you can run the following code:

install.packages("MatchIt")
data("lalonde", package = "MatchIt")
m <- MatchIt::matchit(treat ~ age + educ + race + re74,
  data = lalonde, caliper = .01)
summary(m)$nn

If the caliper is working correctly, you should see a small matrix that has
the row

Matched88  88

If not, you would see the row

Matched   185 185

The GitHub issue of people complaining about this is here
 along with their
explanations about versions of *MatchIt* and R. The package code is also
there.

Any thoughts or insights about this would really help! Thank you so much!

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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 solution is just writing explicit, robust code that should always work.
Thank you!

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[Noah Greifer]

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(). A
few things are confusing to me, so I'm not sure how to solve it.

First, the covariance matrices should be identical; there is no random
component in their computation and the the only difference in the calls
used to generate them are whether an argument is omitted or whether it is
explicitly set to its default (i.e., the purpose of the test is to ensure
the default argument corresponds to the supplied argument). I am willing to
accept that there is some non-deterministic process in ATLAS, e.g., where
convergence is measured based on time rather than number of iterations,
though I don't know if this is actually the case.

Second, the package tests have passed on previous CRAN checks (this is
weeks after this version was accepted to CRAN), on all other versions of R,
and in the rhub test

with ATLAS.

Does anyone have any advice on how to solve this? I know I can change the
tolerance argument to check_equal() but this is a case where the output
should be identical. I cannot reproduce the problem with rhub, so I can't
see where the problem is. Could this be a false alarm due to caching?
Thanks for any insights.

Noah

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel