Sugar median with unit tests

[nathan-russell]

As discussed in #424, this adds a sugar function Rcpp::median with corresponding unit tests.

[eddelbuettel]

I have a much newer version of this line but then I never said anything official about it...

[eddelbuettel]

This looks good. I had in the back of my mind a though that R's median() had a bazillion further options, but maybe I was thinking about quantile() and its (crazy but impressive) type= argument.

So this is probably good too but one or two seconds would be nice.

[nathan-russell]

Okay, that sounds good. In the meantime I will make the appropriate changes regarding your comments above. Is this the newer version of the formatting line you referred to:

-*- mode: C++; c-indent-level: 4; c-basic-offset: 4; indent-tabs-mode: nil; -*-

[eddelbuettel]

Yep. Hard tabs are evil, which we learned eventually. But I leave commits touching every single file to @kevinushey :) -- in short, bulk changes aren't worth it either.

There isn't too much about code style you don't already know or do. Four spaces is better than too, indentation pretty much like R Core and other sensible people do etc pp. No biggies.

[nathan-russell]

Agreed on the spaces vs. tabs - it was just sloppy copy & paste on my part from another sugar file, and being a vim guy (sorry!) the outdated formatting settings didn't catch my eye.

[kevinushey]

FWIW we now use .dir-locals.el to enforce indentation rules when editing with Emacs; does Vim have an analogue for directory-local variables / indentation rules?

[kevinushey]

Just to confirm -- we clone the vector here because the std:: algorithm we use will modify the passed vector?

[thirdwing]

Maybe we can also have a .vim.custom to set indent.

But if we really want to have a consistent coding style, we might think about cpplint from Google.

[eddelbuettel]

Re .dir-locals.el, the fanciest / most general scheme I know is via editorconfig where, as I understand it, you define a 'policy' or outcome and the editor-specific plugins implement it in the editor of choice.

Alternatively, and there clang-format but all of that is a bit of the heavy-handed side.

[eddelbuettel]

My bad for the close and re-open. Hit the wrong button.

[kevinushey]

Other than some minor comments this looks good to me.

[nathan-russell]

@kevinushey Thanks for the feedback - I do believe it is necessary to call Rcpp::clone in the constructor as above. I just did a rebuild without the use of clone and it appears to modify the original vector:

#include <Rcpp.h>

// [[Rcpp::export]]
double median_dbl(Rcpp::NumericVector x, bool na_rm = false) {
    return Rcpp::median(x, na_rm);
}

// [[Rcpp::export]]
double median_int(Rcpp::IntegerVector x, bool na_rm = false) {
    return Rcpp::median(x, na_rm);
}

// [[Rcpp::export]]
Rcomplex median_cx(Rcpp::ComplexVector x, bool na_rm = false) {
    return Rcpp::median(x, na_rm);
}

// [[Rcpp::export]]
Rcpp::String median_ch(Rcpp::CharacterVector x, bool na_rm = false) {
    return Rcpp::median(x, na_rm);
}


/*** R

set.seed(123)
(xx <- rnorm(5))
#[1] -0.56047565 -0.23017749  1.55870831  0.07050839  0.12928774

median_dbl(xx)
#[1] 0.07050839

xx
#[1] -0.56047565 -0.23017749  0.07050839  0.12928774  1.55870831

set.seed(123)
(xx <- as.integer(rpois(5, 20)))
#[1] 17 25 12 20 27

median_int(xx)
#[1] 20

xx
#[1] 17 12 20 25 27

set.seed(123)
(xx <- rnorm(5) + 2i)
#[1] -0.560476+2i -0.230177+2i  1.558708+2i  0.070508+2i  0.129288+2i

median_cx(xx)
#[1] 0.070508+2i

xx
#[1] -0.560476+2i -0.230177+2i  0.070508+2i  0.129288+2i  1.558708+2i

set.seed(123)
(xx <- sample(letters, 5))
#[1] "h" "t" "j" "u" "w"

median_ch(xx)
#[1] "t"

xx
##[1] "h" "j" "t" "u" "w"

*/

---

As for the other points, I'll set RTYPE2 to RESULT_RTYPE and swap out the switch statement with an if statement and commit the changes.

I have not used / am not aware of anything analogous to .dir-locals.el or the Emacs configuration lines embedded in the Rcpp headers; I just have the standard ~/.vimrc and ~/.vim/ftplugin/*.vim files on my machines.

[eddelbuettel]

Time to pull this one in!

[nathan-russell]

👍

[eddelbuettel]

No, thumbs up to you -- that was really well done (but I was a little tied up yesterday and the day before).