First pass at adding Rcpp::algorithm

[dcdillon]

This is a first pass at #426. It only does simple things and is intended as a simple example of what we can do with iterator based algorithms. I'd like to use this and get the discussion started.

Also, suggestions of other algorithms to implement can be added to this once we decide if we'd like to go forward with it.

@thirdwing - I ended up making a helper namespace to contain function objects. I think this addresses your comment in the issue conversation.

[eddelbuettel]

Do we need to template this to allow (at least) int and complex to play along too?

[thirdwing]

Actually the comment is from @nathan-russell

[dcdillon]

It should work for int. Complex needs to be done yet.
On Jan 23, 2016 5:36 PM, "Qiang Kou (KK)" notifications@github.com wrote:

Actually the comment is from @nathan-russell
https://github.com/nathan-russell

—
Reply to this email directly or view it on GitHub
#428 (comment).

[dcdillon]

Just for the sake of it, I'd like to say that if we decide to implement this, we can't say "well it doesn't handle X" so we can't bring it in. We have infinite flexibility to add things later on because this is a totally new API.

[nathan-russell]

@dcdillon This looks good. And regarding my comment in #426, the use of functors for algorithms that keep some sort of state between successive function calls is just the default approach I usually take in such situations, since it offers separation of the subroutine logic (i.e. what's done in the body of some_functor::operator()) and how it is applied (e.g. using std::transform, std::for_each, ...) to a larger object. But you are absolutely right that this could just as well be done with helper functions instead, so please don't feel compelled to incorporate my suggestion if it doesn't seem like the most sensible approach to take.

[kevinushey]

nit: a non-plural name is slightly preferred (e.g. <Rcpp/algorithm.hpp>); just to be in-line with the STL <algorithm> header. Also since the namespace name is algorithm after all.

[eddelbuettel]

👍

[eddelbuettel]

@kevinushey I'm on a little on the fence.

If there were sufficient commitment and excitement for "sure, let's go off and reimplement all this" I'd be more inclined. Right now I see it as potentially disruptive for no real obvious gain (as we do have these functions in Rcpp Sugar). On the other hand by keeping it in a distinct sub-namespace it can't do too much damage. We could also develop this in a branch and see where it leads us.

Overall somewhat ¯_(ツ)_/¯. I'll talk some more with @dcdillon over some hot or cold beverages.

[dcdillon]

I changed the names of the functions and added a proof of concept as to how things could be templated as @kevinushey suggested.

[dcdillon]

A quick response to @eddelbuettel regarding the utility of these type of functions.

I came up with the idea when looking at an SO question regarding RcppParallel where someone was trying to use sugar functions on RVector and RMatrix an it occurred to me that making iterator based algorithms for some (all?) of the sugar functions would allow them to be used with types other than Rcpp::Vector, etc. If there's no interest I can drop it, but it seems like there would be some utility in doing it.

[eddelbuettel]

Right. That would be a good use case but we need to be very careful. The reason RVector and RMatrix are apart is that any interaction with R via a SEXP, or a callback, or ... could tickle a gc event and busting the parallel computation.

[eddelbuettel]

Anyway -- I really do like our deliberate approach here of discussion first. A welcome change.

[dcdillon]

Yeah. I wouldn't have PR'ed at all, except without some code to talk about it's much harder to have a conversation.

[dcdillon]

Sorry about the broken builds. My testing apparently wasn't giving me the results I needed.

Anyhow, it got a little convoluted, but the end result is good. I created classes that take a c++ type as a parameter and, in turn, provide information about the R types. Specifically RTYPE, NA, ZERO, and ONE. This may be useful elsewhere, but I've kept it confined to Rcpp::algorithm for now.

[dcdillon]

Will revisit this after the next release.

[dcdillon]

I wanted to bump this again, as it pertains directly to the fixes that just had to go in to Rcpp::min and Rcpp::max due to #477.

Due to the way most of Rcpp::sugar is implemented (it relies heavily on casting operators and redefinitions of things that are already well defined) this sort of problem will keep cropping up in the future.

An iterator-based algorithm approach (where it makes sense) would alleviate these and also render the preponderance of duplicated code that currently exists in Rcpp::sugar unnecessary.

[eddelbuettel]

How do we get from here to there?

Any alternative to incrementalism as we just did for max() and min() ?

[dcdillon]

• Implement a subset of the Rcpp::sugar algorithms as iterator-based algos without connecting them to anything.
• Create unit tests for these on Rcpp::Vector
• Once the unit tests pass, start reimplementing the Rcpp::sugar variants and DO NOT CHANGE the current unit tests.

[dcdillon]

OK. So because I'm stupid and deleted the fork that this PR came from, I have had to create a new one.

Sorry..will have to close this one and open a new one to continue the work.