[R-pkg-devel] Question on Description/Citing Feedback

[Michael Topper]

Hello all,

I just received feedback from my first CRAN submission. Currently, I am a
little confused as to one point of the feedback which reads:









*If there are references describing the methods in your package, pleaseadd
these in the description field of your DESCRIPTION file in the formauthors
(year) authors (year) authors (year, ISBN:...)or if
those are not available: with no space after 'doi:', 'arXiv:',
'https:' and angle brackets forauto-linking. (If you want to add a title as
well please put it inquotes: "Title")*

For some background:

   - My package is named panelsummary. The link to the github can be found
   here: https://github.com/michaeltopper1/panelsummary
   - My package inherits some documentation of some of the parameters from
   the package modelsummary
   . In particular, two
   of my functions (panelsummary::panelsummary and
   panelsummary::panelsummary_raw) share a couple of the same arguments as
   modelsummary::modelsummary. I used roxygen2 (@inherits) to generate
   documentation for the shared arguments.
   - Because of this inherited documentation, I have also included the
   author/creator of modelsummary as a copyright holder in the DESCRIPTION
   file with a comment.


My confusion:

   - I understand the Description portion of the DESCRIPTION file needs to
   be edited, but I'm a little confused as to what I am supposed to add and
   how. Do I need to include a citation to the published paper of
   modelsummary and describe where I use the documentation? Modelsummary was
   published in the journal of statistical software and the following was
   included on the modelsummary release information:
  - Arel-Bundock, Vincent (2022). “modelsummary: Data and Model
  Summaries in R.” Journal of Statistical Software, 103(1), 1-23.
  doi:10.18637/jss.v103.i01 https://doi.org/10.18637/jss.v103.i01.’

What would be most helpful:

   - If there is any other Description file from another package that
   contains an example of what to do in such a situation, this would be
   greatly appreciated!

Please let me know if any additional details are needed, and thank you so
much for your help/time!

Michael

[[alternative HTML version deleted]]

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

[R-pkg-devel] Examples are too long in computation for CRAN

[Michael Topper]

Hello all,

Not sure how to handle this, as it had not been an issue on my previous
CRAN submissions. It appears that some of my examples/tests are taking too
long to run for CRAN's standards. Is there a way around this other than the
simple "change the example" or "change the test"?

Moreover, is there any insight as to why this would happen on the third
update of the package rather than on the first or second?

Thanks in advance, and see below for the NOTE:


Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: NOTE
  Examples with CPU (user + system) or elapsed time > 5s
user system elapsed
  panelsummary 9.574  0.273   0.817
  panelsummary_raw 6.048  0.164   0.450
  Examples with CPU time > 2.5 times elapsed time
user system elapsed  ratio
  panelsummary_raw 6.048  0.164   0.450 13.804
  panelsummary 9.574  0.273   0.817 12.053
  clean_raw3.684  0.064   0.514  7.292

Flavor: r-devel-linux-x86_64-debian-gcc
Check: tests, Result: NOTE
Running 'testthat.R' [54s/6s]
  Running R code in 'testthat.R' had CPU time 9.3 times elapsed time

[[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] Examples are too long in computation for CRAN

[Michael Topper]

I have tried the following:

   - Trimming down the examples substantially to only run 1 regression
   per-function.
   - Setting the nthreads argument to 2 in fixest::feels() in case this is
   the problem as suggested.
   - Tried to use skip_cran_test() on the tests that include fixest
   regressions

However, while the time has substantially been trimmed down, it still does
not pass. At this point, I'm not sure what the next step is.

Below is the results:

Flavor: r-devel-linux-x86_64-debian-gcc
Check: examples, Result: NOTE
  Examples with CPU time > 2.5 times elapsed time
user system elapsed ratio
  panelsummary_raw 3.354  0.054   0.461 7.393
  clean_raw3.436  0.091   0.571 6.177
  panelsummary 3.636  0.136   0.824 4.578

Flavor: r-devel-linux-x86_64-debian-gcc
Check: tests, Result: NOTE
Running 'testthat.R' [39s/4s]
  Running R code in 'testthat.R' had CPU time 8.7 times elapsed time

On Sat, Aug 12, 2023 at 11:26 PM Uwe Ligges 
wrote:

>
>
> On 13.08.2023 08:14, Ivan Krylov wrote:
> > В Sat, 12 Aug 2023 22:49:01 -0700
> > Michael Topper  пишет:
> >
> >> It appears that some of my examples/tests are taking too
> >> long to run for CRAN's standards.
> >
> > I don't think they are running too long; I think they are too parallel.
> > The elapsed time is below 1s, but the "user" time (CPU time spent in
> > the process) is 7 to 13 times that. This suggests that your code
> > resulted in starting more threads than CRAN allows (up to 2 if you have
> > to test parallellism). Are you using OpenMP? data.table? makeCluster()?
> > It's simplest to always to default to a parallelism factor of 2 in
> > examples an tests, because determining the right number is a hard
> > problem. (What if the computer is busy doing something else? What if
> > the BLAS is already parallel enough?)
> >
> >> Moreover, is there any insight as to why this would happen on the
> >> third update of the package rather than on the first or second?
> >
> > The rule has always depended on the particular system running the
> > checks (five seconds on my 12-year-old ThinkPad or on my ultraportative
> > with an Intel Atom that had snails in its ancestry?). Maybe some
> > dependency of your package has updated and started creating threads
> > where it previously didn't.
> >
>
>
> Good points, not only for examples and tests, but also for defaults.
>
> On shared resources (such as clusters) users may not expect the
> parallelization you use and then overallocate the resources.
>
> Example: 20 cores available to the user who runs makeCluster() for
> paallelization, but the underlying code does multihreading on 20 cores.
> Then we end up in 20*20 threads on the machine slowing down the machine
> and processes of other uers.
> Hence, defaults should also not be more than 2. Simply allow the user to
> ask for more.
>
> Best,
> Uwe Ligges
>


-- 
Michael Topper
B.S. Economics and Mathematics, University of California San Diego 2015
M.A. Economics, San Diego State University 2018
Mobile: (805) 914-4285
miketopper...@gmail.com

[[alternative HTML version deleted]]

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