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