1

Rcpp Gallery explains how to shuffle a vector using Rcpp.

However, it uses std::random_shuffle(), which is no longer supported in C++17. I naively replaced std::random_shuffle() with std::shuffle(), but it did not work with C++17.

instantiation of function template specialization 'std::shuffle<std::__wrap_iter<int *>, int (&)(int)>' requested here

I suppose it's because std::random_shuffle() takes RandomFunc but std::shuffle() in C++17 takes URBG (reference).

How can we make this code work with C++17? (How can we define UniformRandomBitGenerator using the R randomization feature?)

inline int randWrapper(const int n) { return floor(unif_rand()*n); }

// [[Rcpp::export]]
Rcpp::NumericVector randomShuffle(Rcpp::NumericVector a) {

    // clone a into b to leave a alone
    Rcpp::NumericVector b = Rcpp::clone(a);

    std::random_shuffle(b.begin(), b.end(), randWrapper);

    return b;
}

My code is more complex than this, but it uses the same trick. It works fine if I link Rcpp with C++11 but not with C++17.

I would like to get the same results from C++17 as well (i.e., I would like to use an R randomizer and make sure the results won't change by changing it from C++11 to C++17).

Now CRAN does not accept C++11 so I need to fix it.

user51966
  • 967
  • 3
  • 9
  • 21
  • you should show the code where you replaced `random_shuffle` with `shuffle` – 463035818_is_not_an_ai Jan 28 '23 at 12:54
  • It's exactly the same code but using `shuffle` instead of `random_shuffle`: `std::shuffle(b.begin(), b.end(), randWrapper);`. – user51966 Jan 28 '23 at 12:58
  • if it was only a rename then there would have been no point in deprecating it. You need to read some documentation to see what you should pass as argument instead https://en.cppreference.com/w/cpp/algorithm/random_shuffle – 463035818_is_not_an_ai Jan 28 '23 at 12:59
  • If you can't make it work with `std::shuffle` (for some obscure reason), just implement the shuffling algorithm yourself. It's really simple. – Ted Lyngmo Jan 28 '23 at 13:07
  • "Now CRAN does not accept C++11 so I need to fix it." is demonstrably false as *many* packages impose it. R itself now defaults to C++14 (if nothing else is set) but of course still allows C++11 as that is a valid C++ standard. – Dirk Eddelbuettel Jan 28 '23 at 14:08
  • @DirkEddelbuettel Now the CRAN check raises a NOTE on this. For example, this package: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/ggraph-00check.html I suppose CRAN changed (or is changing) its policy but I might get confused. – user51966 Jan 28 '23 at 15:01
  • That is a) a completely different story you seem to misunderstand (CRAN just suggesting to move from C++11 to C++17 as a package-imposed choice; there is zero information here about CRAN forbidding C++11 as you claimed) and b) I am aware [as I tweeted about just that last night](https://twitter.com/eddelbuettel/status/1619196698693365762) and c) (but you cannot know this) am also in email about this with CRAN maintainers. In short: you still misread, and hence accidentally spread misinformation. C++11 remains of course possible and permitted at CRAN. – Dirk Eddelbuettel Jan 28 '23 at 15:05
  • I didn't mean to spread the wrong information, but our team got a confusing email that said "CRAN submissions will now auto-reject packages with this NOTE." Does it mean package maintainers cannot update their package if they use C++11? – user51966 Jan 28 '23 at 15:13
  • Also not correct as stated. Packages with WARNING and ERROR are auto-rejected. Packages with NOTE go to a manual inspection; many NOTEs are known false positives (spelling in DESCIPTION is a common one) and argued away. What you and I both noticed is brand-new and currently only in r-devel; sometimes these are also altered. (In the grand scheme it's all good as CRAN not only allows C++17 but is also moving its baseline from C++14 (currently in R 4.2.*) to C++17.) – Dirk Eddelbuettel Jan 28 '23 at 15:16
  • Lastly: Yoiur bug report on the Rcpp Gallery is valid. It's a pain (and rare) when C++ changes and old code goes away but it sometimes does. I would love a PR at the Rcpp Gallery for this post if/when you get it worked out. I am sure there are other example you can lean on. – Dirk Eddelbuettel Jan 28 '23 at 15:17
  • OK, my team got confused because the email from the CRAN team said "auto-reject packages with this NOTE." ("auto-reject" sounds like it doesn't go to a manual inspection) It's great to know you already reached out to the CRAN team, thank you. – user51966 Jan 28 '23 at 15:31
  • This sentence further down is relevant: "If you are fairly certain the rejection is a false positive, please reply-all to this message and explain.". I get that auto-archive for Rcpp on each upload (see it's CRAN package page and its check results, it's a "grandfathered" exception) so I have to go through this each and every time; same with another package or two among my set. Auto-admittance is much smoother but hey we can't always have it. Finally, come to the `r-pkg-devel` list for these questions. Very friendly with high signal-to-noise. – Dirk Eddelbuettel Jan 28 '23 at 15:41
  • 1
    Correction: I was wrong above. CRAN does in fact want C++17 now, and r-devel flags it. I thought this was still 'in test' but it is indeed live. I just updated one package of mine accordingly. – Dirk Eddelbuettel Feb 01 '23 at 23:43

0 Answers0