Thanks for feedback, Dirk. This make sense - unlikely sparsepp will be used without Rcpp (my idea was to have as small dependencies as possible). I will add Rcpp to suggests.
2016-12-31 15:00 GMT+04:00 <rcpp-devel-requ...@lists.r-forge.r-project.org>: > Send Rcpp-devel mailing list submissions to > rcpp-devel@lists.r-forge.r-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.r-forge.r-project.org/cgi-bin/mailman/ > listinfo/rcpp-devel > > or, via email, send a message with subject or body 'help' to > rcpp-devel-requ...@lists.r-forge.r-project.org > > You can reach the person managing the list at > rcpp-devel-ow...@lists.r-forge.r-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rcpp-devel digest..." > > > Today's Topics: > > 1. [small ann] Sparse++ (Dmitriy Selivanov) > 2. Re: [small ann] Sparse++ (Dirk Eddelbuettel) > 3. Re: Rcpp Timer (Dirk Eddelbuettel) > 4. Re: Rcpp Timer (Dirk Eddelbuettel) > 5. Re: Rcpp Timer (Romain Francois) > 6. Re: Rcpp Timer (Dirk Eddelbuettel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 30 Dec 2016 15:49:42 +0400 > From: Dmitriy Selivanov <selivanov.dmit...@gmail.com> > To: rcpp-devel@lists.r-forge.r-project.org > Subject: [Rcpp-devel] [small ann] Sparse++ > Message-ID: > <CAJdZCv3j7-DW4HkaSkNs-uHcMwc7s2+YUOhJT6Yrz=k05ggN8A@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello mailing list. Just small announcement. I made package "sparsepp" > which brings bindings to header only 'sparsepp' library - > https://github.com/greg7mdp/sparsepp. It is on CRAN already. Sparse++ is > improvement over google sparse hash library (see this write-up > https://github.com/greg7mdp/sparsepp/blob/master/bench.md). > > Initially I evaluated it with my text2vec package, where main data > structure is unordered_map< pair<uint32_t, uint32_t>, T >, where T is int > or float. > In my case memory improvement was 2x and speed up was 1.5x (lookup and > insert operations). > > So I decided to build small package which can be used by other people (not > text2vec only). > > Usage is as usual > > 1. add to DESCRIPTION of your package: LinkingTo: sparsepp > 2. add #include <sparsepp.h> to you source/header > 3. use spp::sparse_hash_map as drop-in replacement for > std::unordered_map > . > > -- > Regards > Dmitriy Selivanov > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: <http://lists.r-forge.r-project.org/pipermail/rcpp- > devel/attachments/20161230/d3038ad2/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Fri, 30 Dec 2016 06:26:35 -0600 > From: Dirk Eddelbuettel <e...@debian.org> > To: Dmitriy Selivanov <selivanov.dmit...@gmail.com> > Cc: rcpp-devel@lists.r-forge.r-project.org > Subject: Re: [Rcpp-devel] [small ann] Sparse++ > Message-ID: <22630.21115.213619.66...@max.nulle.part> > Content-Type: text/plain; charset=iso-8859-1 > > > On 30 December 2016 at 15:49, Dmitriy Selivanov wrote: > | Hello mailing list. Just small announcement. I made package "sparsepp" > ?which > | brings bindings to header only 'sparsepp' library ?-?https://github.com/ > | greg7mdp/sparsepp. It is on CRAN already. Sparse++ is improvement over > google > | sparse hash library (see this write-up https://github.com/greg7mdp/ > sparsepp/ > | blob/master/bench.md). > | > | Initially I evaluated it with my text2vec package, where main data > structure > | is?unordered_map< pair<uint32_t, uint32_t>, T >, where T is int or float. > | In my case memory improvement was 2x and speed up was 1.5x (lookup and > insert > | operations). > | > | So I decided to build small package which can be used by other people > (not > | text2vec only). > | > | Usage is as usual? > | > | 1. add to DESCRIPTION of your package: LinkingTo: sparsepp > | 2. add #include <sparsepp.h>?to you source/header? > | 3. use?spp::sparse_hash_map?as drop-in replacement > for?std::unordered_map. > > Thanks, possibly very useful. > > Now, should it have at least a 'Suggests: Rcpp' if the example requires it, > \dontrun{} or not? Also examine whose project you're posting on. > > Sure it "could" be used from R without Rcpp. But how likely is that? > Suggests is for exactly that reason, at least in my book. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > ------------------------------ > > Message: 3 > Date: Fri, 30 Dec 2016 06:37:55 -0600 > From: Dirk Eddelbuettel <e...@debian.org> > To: Jonathan Christensen <dzhona...@gmail.com> > Cc: rcpp-devel@lists.r-forge.r-project.org, Kaspar M?rtens > <kaspar.mart...@gmail.com> > Subject: Re: [Rcpp-devel] Rcpp Timer > Message-ID: <22630.21795.782989.138...@max.nulle.part> > Content-Type: text/plain; charset=iso-8859-1 > > > On 29 December 2016 at 11:25, Jonathan Christensen wrote: > | Hi Kaspar and Dirk, > | > | It is indeed cumulative. Previously (presumably when that gallery page > was > | written) it was not cumulative, but Romain Francois changed the behavior > of the > | step() function several years ago, in this commit:?https://github.com/ > RcppCore/ > | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. > > Nice catch. > > | There is no indication or reasoning about changing the behavior, so it > may be > | that making it cumulative was unintentional. > > Let's presume it was intentional to the author of the change -- but as you > rightly point out, it did of course change and reverse previous behaviour. > > We could easily add a toggle to the constructor to get an either/or > behaviour. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > ------------------------------ > > Message: 4 > Date: Fri, 30 Dec 2016 07:01:48 -0600 > From: Dirk Eddelbuettel <e...@debian.org> > To: Dirk Eddelbuettel <e...@debian.org> > Cc: Kaspar M?rtens <kaspar.mart...@gmail.com>, > rcpp-devel@lists.r-forge.r-project.org > Subject: Re: [Rcpp-devel] Rcpp Timer > Message-ID: <22630.23228.969582.535...@max.nulle.part> > Content-Type: text/plain; charset=iso-8859-1 > > > On 30 December 2016 at 06:37, Dirk Eddelbuettel wrote: > | > | On 29 December 2016 at 11:25, Jonathan Christensen wrote: > | | Hi Kaspar and Dirk, > | | > | | It is indeed cumulative. Previously (presumably when that gallery page > was > | | written) it was not cumulative, but Romain Francois changed the > behavior of the > | | step() function several years ago, in this commit:?https://github.com/ > RcppCore/ > | | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. > | > | Nice catch. > | > | | There is no indication or reasoning about changing the behavior, so it > may be > | | that making it cumulative was unintentional. > | > | Let's presume it was intentional to the author of the change -- but as > you > | rightly point out, it did of course change and reverse previous > behaviour. > | > | We could easily add a toggle to the constructor to get an either/or > behaviour. > > Even easier: > - Add a step() call immediately after creating timer() > - This also records the start > - Results are still cumulative > - Running diff() over it shows changes: > > Demo using minimally modified Rcpp Gallery piece (just added > step("start"); ) > > R> sourceCpp("/tmp/timer.cpp") > > R> tt <- useTimer() > > R> tt # cumulative > start get/put g/p+rnorm() empty loop > 0.000114 1629.043000 3996.890739 3996.893329 > > R> diff(tt) # incremental > get/put g/p+rnorm() empty loop > 1629.04289 2367.84774 0.00259 > R> > > I will alter the gallery story accordingly. We can always add a 'zero' step > to the constructor to get these two behaviours cheaply. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > ------------------------------ > > Message: 5 > Date: Fri, 30 Dec 2016 20:38:55 +0100 > From: Romain Francois <rom...@r-enthusiasts.com> > To: Dirk Eddelbuettel <e...@debian.org> > Cc: Kaspar M?rtens <kaspar.mart...@gmail.com>, > rcpp-devel@lists.r-forge.r-project.org > Subject: Re: [Rcpp-devel] Rcpp Timer > Message-ID: <0b8a3af5-91c5-40d5-aea3-92a2846db...@r-enthusiasts.com> > Content-Type: text/plain; charset=utf-8 > > It made more sense to track times since an origin, esp when you might use > several timers in case you use multiple threads. > > > > Le 30 d?c. 2016 ? 13:37, Dirk Eddelbuettel <e...@debian.org> a ?crit : > > > > > > On 29 December 2016 at 11:25, Jonathan Christensen wrote: > > | Hi Kaspar and Dirk, > > | > > | It is indeed cumulative. Previously (presumably when that gallery page > was > > | written) it was not cumulative, but Romain Francois changed the > behavior of the > > | step() function several years ago, in this commit: > https://github.com/RcppCore/ > > | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. > > > > Nice catch. > > > > | There is no indication or reasoning about changing the behavior, so it > may be > > | that making it cumulative was unintentional. > > > > Let's presume it was intentional to the author of the change -- but as > you > > rightly point out, it did of course change and reverse previous > behaviour. > > > > We could easily add a toggle to the constructor to get an either/or > behaviour. > > > > Dirk > > > > -- > > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > _______________________________________________ > > Rcpp-devel mailing list > > Rcpp-devel@lists.r-forge.r-project.org > > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > > > ------------------------------ > > Message: 6 > Date: Fri, 30 Dec 2016 13:58:10 -0600 > From: Dirk Eddelbuettel <e...@debian.org> > To: Romain Francois <rom...@r-enthusiasts.com> > Cc: Kaspar M?rtens <kaspar.mart...@gmail.com>, > rcpp-devel@lists.r-forge.r-project.org > Subject: Re: [Rcpp-devel] Rcpp Timer > Message-ID: <22630.48210.639061.279...@max.nulle.part> > Content-Type: text/plain; charset=iso-8859-1 > > > On 30 December 2016 at 20:38, Romain Francois wrote: > | It made more sense to track times since an origin, esp when you might > use several timers in case you use multiple threads. > > Using an offset to an origin (and hence differences) is also a sensible way > to deal with higher resolutions. We cannot natively represent nanoseconds > (which the Timer class uses) in R with base types: doubles use 53 bits > precision which gets us a bit more than microseconds, and ints are 32 bit > -- > so conversion would be lossy. (The nanoseconds package I just releases > uses > bit64::integer64 which gets us nanosecond, but that is a higher-level > depend > and not something we want to depend on at the Rcpp level). > > Whether cumulative times, or individual measurements is better is still > open > fore debate. In any event, I fixed the Rcpp Gallery story at > > http://gallery.rcpp.org/articles/using-the-rcpp-timer/ > > Dirk > > | > Le 30 d?c. 2016 ? 13:37, Dirk Eddelbuettel <e...@debian.org> a ?crit : > | > > | > > | > On 29 December 2016 at 11:25, Jonathan Christensen wrote: > | > | Hi Kaspar and Dirk, > | > | > | > | It is indeed cumulative. Previously (presumably when that gallery > page was > | > | written) it was not cumulative, but Romain Francois changed the > behavior of the > | > | step() function several years ago, in this commit: > https://github.com/RcppCore/ > | > | Rcpp/commit/e295b2b178de55291e63705966368404bb0ce5e1. > | > > | > Nice catch. > | > > | > | There is no indication or reasoning about changing the behavior, so > it may be > | > | that making it cumulative was unintentional. > | > > | > Let's presume it was intentional to the author of the change -- but as > you > | > rightly point out, it did of course change and reverse previous > behaviour. > | > > | > We could easily add a toggle to the constructor to get an either/or > behaviour. > | > > | > Dirk > | > > | > -- > | > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > | > _______________________________________________ > | > Rcpp-devel mailing list > | > Rcpp-devel@lists.r-forge.r-project.org > | > https://lists.r-forge.r-project.org/cgi-bin/mailman/ > listinfo/rcpp-devel > | > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > > ------------------------------ > > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel > > End of Rcpp-devel Digest, Vol 86, Issue 14 > ****************************************** > -- Regards Dmitriy Selivanov
_______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
