Header-only patch #29
Conversation
|
Interesting :) @adamjohansen and I will review. I just noticed that Travis may not have been "on" (my mistake) since we moved this into its own org. Did you have a Travis test for this? |
|
Looks good locally Looks good. |
|
Would you do us the favour and reveal a little more than You know who we are. |
|
Looks good to me too: I'll have a proper look later... but it looks pretty uncontroversial. Thanks for the fix. |
There was a problem hiding this comment.
There's the philosophical question of how far one is prepared to go in squeezing code into headers in order to avoid some linking.
I don't think this PR goes too far, and I can see advantages so I'm fine with this.
Thanks to the mysterious @mlysy.
| double dMaxWeight = arma::max(logw); | ||
| double sum = arma::sum(exp(logw - dMaxWeight)); | ||
| return (dMaxWeight + log(sum)); | ||
| } |
There was a problem hiding this comment.
I have a vague aesthetic objection to non-templated code in header files, but that's because I'm a dinosaur. With inline functions I guess it doesn't matter anyway, so I don't have a problem with it if @eddelbuettel is happy. I can see at least small advantages in keeping the library side of the code header only if it doesn't cause other problems.
| @@ -76,5 +76,98 @@ namespace smc { | |||
| /// Returns the empirical covariance matrix based on the current weighted particle set. | |||
| arma::mat GetEmpCov(void) const {return empCov;} | |||
| }; | |||
|
|
|||
There was a problem hiding this comment.
Again, you could debate whether all of what follows belongs inline in headers; much of this is prototypical code that a user would need to replicate to implement a different adaptation scheme, but again I don't feel particularly strongly either way.
|
Yes, people also debate longer compile times (true) versus the fact that here we would have it much easier to let others use this just via headers (RcppArmadillo-style). I tend to side with "headers-only is good" for the easier use case. but try not to be dogmatic. Would still be nice to know who we got this from. Could you email Adam and/or myself what name we should use for you were we to merge this? |
|
Dear package developers, Oh my...did not mean to come off as mysterious. My name is Martin Lysy. I'm very glad you're considering the merge. I am using |
|
Thanks, Martin, much appreciated. I am following a GNU convention of logging changes in a file ChangeLog with a standard "Date Name Email" header of each paragraph (and Emacs automates this). You git commit had no traces to a real name, or email which is why I asked. I'll fill in based on And I with you: |
|
Yes, thanks Martin... I wasn't trying to be difficult and what you've done certainly makes sense. Good code's always welcome, and much appreciated. |
|
Thanks guys! I really enjoyed looking through this library and studying some of your programming tricks. I hope you don't mind if I contact you down the road with some other feature/pull requests which hopefully aren't purely self-serving...I'll follow Dirk's advice to start with an "issue" first to get your feedback on whether/how to proceed. |
|
Don't run away we still need you :) I started riffing on the commuter train this morning (but my ride is short) about making a "plugin" so that we can do Also, as you're in Waterlook, say Hi to Marius Hofert ... |
|
I'm happy to make one and send it over. One issue I did neglect though is that since the smctc header file now does How do you guys feel about this? To my recollection the dependence on RcppArmadillo is very minor, and I'd be happy to rewrite it using "plain" C++... |
|
No, we added Armadillo on purpose last summer. Also, Which strikes me as a good thing. |
|
I have no issue with |
|
OK I wrote a simple test case for the
//[[Rcpp::depends("RcppArmadillo")]]
//[[Rcpp::depends("RcppSMC")]]
# compile on-the-fly with Rcpp::depends("RcppSMC")
Rcpp::sourceCpp(file = "pflineart_honly.cpp")
source("pfLineartBS_honly.R") # the R wrapper
# compare to RcppSMC version
require(RcppSMC)
linData <- simLineart() # simulate data
set.seed(1043)
pf1 <- pfLineartBS(data = linData$data, plot = FALSE) # with RcppSMC
set.seed(1043)
pf2 <- pfLineartBS_honly(data = linData$data, plot = FALSE) # with Rcpp::depends
identical(pf1, pf2) # should be the samePlease let me know whether/how I should incorporate these files into the package. I know Dirk is not too keen on |
|
For the package main you don't need it. The |
Dear
RcppSMCdevelopers,Love the library. I tried to use it in an R/C++ package through the
//[[Rcpp::depends(RcppSMC)]]mechanism, but the compiler couldn't find a couple of cpp files insrcthat (presumably) should have been ininst/include. This patch relocates the contents of these files while keeping things headers-only.