I am sorry but why do you suggest all of a sudden to patch your code in our package? I mean 🤷‍♂️ sure why not but why not rely on what we have for ten years and have your release signify your release?

And of course, don't get me wrong a bug is a bug and a bug needs fixing but ... around here people look first for the Rcpp (Sugar) vectorised functions, and that one works:

> library(Rcpp)> cppFunction("arma::vec arma_sign(arma::vec d) { return arma::sign(d); }",depends="RcppArmadillo")> sapply(c(-1,0,1,NA,NaN),arma_sign)[1]-10100>> cppFunction("NumericVector rcpp_sign(NumericVector d) { NumericVector x(sign(d)); return x;}")> sapply(c(-1,0,1,NA,NaN),rcpp_sign)[1]-101NANA>

So I think we can just wait this out to the next upgrade.

1. Thercpp::sign() function is notarma::sign(). Thercpp::sign() function doesn't work with armadillo vectors and matrices.
2. As discussed via email late last year, we agreed to reduce the churn in RcppArmadillo releases (ie. keep RcppArmadillo at 0.10.1.x for a long while). I stated that I will send you bug fixes directly as pull requests via GitHub. This is one of the fixes.

Dear Conrad, please consider:

Re 1: Yes, and R users almost always callRcpp:: functions first. Which is why this PR, while technically helpful, may not matter.

Re 2: We have posted some markdown files in various places and stated our position repeatedly: astrong preference for issue tickets and discussion leading to some consensus before unsolicited PRs. Now, granted, this PR is fairly local and focussed but .... this is simply not the right way to go about things.

Especially as every other library I cover as a port or integration to R via Rcpp works via their own well managed git repsository. Yours was always a little, ahem, "special" with your insistence on tarballs with overwritten file timestamps etc. Your code, your repo, your rules, so at some point years ago I gave up pointing this out. This here, however, is our repo so I would appreciate if you could play by its rules. And issue ticket pointed to a commit of yours (over at GitLab) may suffice and make life a lot easier for you too.

Also as discussed last time, it is preferred that PRs come with a corresponding ChangeLog entry in the standard format identifying the author, file, and purpose.

Codecov Report

Merging#321 (193c4fa) intomaster (399c204) willnot change coverage.
The diff coverage isn/a.

@@           Coverage Diff           @@##           master     #321   +/-   ##=======================================  Coverage   34.29%   34.29%           =======================================  Files          65       65             Lines        2356     2356           =======================================  Hits          808      808             Misses       1548     1548

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update399c204...193c4fa. Read thecomment docs.

Incorporporated this by hand indb84fc2 so PR no redundant --> closing