[Rd] Package Rcpp: Question conerning source code of cpp files and related question
Dear all,
I am trying to use Rcpp to write some files in C++ for use in R.
Below is an example for a cpp-file (crossp.cpp). Then I use
>sourceCpp("crossp.cpp") in R and the corresponding function is
availabe in R.
Now I have to question related to this worklfow:
1) Is there a way to see the source file of the "final" cpp-file? (I
mean is it possible to see how the //-lines are replaced and what
soureCpp does?)
2) (Connected with the first question) Up to now, I am working in R
Studio, but I would prefer an IDE (e.g. NetBeans IDE). But when I
compile the cpp-file there, the following message shows up:
In file included from
/R/win-library/3.0/RcppArmadillo/include/RcppArmadilloForward.h:28:0,
from
/R/win-library/3.0/RcppArmadillo/include/RcppArmadillo.h:30,
from crossp.cpp:1:
/R/win-library/3.0/RcppArmadillo/include/RcppArmadilloConfig.h:90:35:
fatal error: RcppArmadilloLapack.h: No such file or directory
#include
Is there an way to compile the file without sourCpp but in an IDE? What
do I have to change?
As I am starting to work with Rcpp my question might sound silly, but
any help and comments are highly welcome.
Thank you very much for your help in advance!
Best,
Martin
crossp.cpp:
#include
// [[Rcpp::depends(RcppArmadillo)]]
using namespace Rcpp;
using namespace arma;
//[[Rcpp::export]]
NumericMatrix crossp3(NumericMatrix Xr) {
int n = Xr.nrow(), k = Xr.ncol();
arma::mat X(Xr.begin(), n, k, false);
arma::mat XXt = X.t()*X;
return Rcpp::wrap(XXt);
}
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Package Rcpp: Question conerning source code of cpp files and related question
On 30 September 2014 at 13:00, Martin Spindler wrote: | I am trying to use Rcpp to write some files in C++ for use in R. Please subscribe to rcpp-devel, and post on that list. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Intel Fortran compiler returns a -1 TRUE value
I have access to a cluster on which I have been supplied with R 3.1.0 which
appears to have been built using the intel compiler tools.
The following minimal Fortran file:
subroutine truth(lind)
logical lind
lind = .TRUE.
end
Compiles thusly:
arcadia> R CMD SHLIB truth.f
ifort -fpic -O3 -xHOST -axCORE-AVX-I -fp-model precise -c truth.f -o
truth.o
ifort: command line warning #10212: -fp-model precise evaluates in source
precision with Fortran.
icc -std=gnu99 -shared -L/usr/local/lib64 -o truth.so truth.o -lifport
-lifcore -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl
And runs so:
> dyn.load("truth.so")
> z = .Fortran("truth",as.logical(TRUE))
> z[[1]]
[1] TRUE
> as.numeric(z[[1]])
[1] -1
> z[[1]] == TRUE
[1] FALSE
> all(z[[1]])
[1] TRUE
> identical(z[[1]],TRUE)
[1] FALSE
The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
conversion to -1 is most unusual, every other system I've tried converts to
+1.
So wrong compiler flag on build? User error - never try comparing
truthy values, as with the various flavours of NA? Or something else?
If its a compiler/config problem I'll pass it on to the cluster admin -
I've had a good look for stuff on building R on Intel compilers, nothing
stood out. I might try building R myself this afternoon but as I implied I
don't have admin on this cluster so I might have to track down a bunch of
library sources to build R from source.
If its a user error then I'll track down every instance of "if(foo==TRUE)"
and shoot it, and it would be nice to have a note in ?TRUE
Some useful info:
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-unknown-linux-gnu (64-bit)
arcadia> ifort -v
ifort version 13.0.0
Thanks
Barry
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On 30/09/2014, 7:41 AM, Barry Rowlingson wrote:
> I have access to a cluster on which I have been supplied with R 3.1.0 which
> appears to have been built using the intel compiler tools.
>
> The following minimal Fortran file:
>
> subroutine truth(lind)
> logical lind
> lind = .TRUE.
> end
>
> Compiles thusly:
>
> arcadia> R CMD SHLIB truth.f
> ifort -fpic -O3 -xHOST -axCORE-AVX-I -fp-model precise -c truth.f -o
> truth.o
> ifort: command line warning #10212: -fp-model precise evaluates in source
> precision with Fortran.
> icc -std=gnu99 -shared -L/usr/local/lib64 -o truth.so truth.o -lifport
> -lifcore -limf -lsvml -lm -lipgo -lirc -lpthread -lirc_s -ldl
>
>
> And runs so:
>
> > dyn.load("truth.so")
> > z = .Fortran("truth",as.logical(TRUE))
> > z[[1]]
> [1] TRUE
> > as.numeric(z[[1]])
> [1] -1
> > z[[1]] == TRUE
> [1] FALSE
> > all(z[[1]])
> [1] TRUE
> > identical(z[[1]],TRUE)
> [1] FALSE
>
> The value generated by Fortran's .TRUE. evaluates as "truthy" -- as in
> all(z[[1]]) -- but is neither equal to nor identical to TRUE. Its numeric
> conversion to -1 is most unusual, every other system I've tried converts to
> +1.
>
> So wrong compiler flag on build? User error - never try comparing
> truthy values, as with the various flavours of NA? Or something else?
>
> If its a compiler/config problem I'll pass it on to the cluster admin -
> I've had a good look for stuff on building R on Intel compilers, nothing
> stood out. I might try building R myself this afternoon but as I implied I
> don't have admin on this cluster so I might have to track down a bunch of
> library sources to build R from source.
>
> If its a user error then I'll track down every instance of "if(foo==TRUE)"
> and shoot it, and it would be nice to have a note in ?TRUE
>
> Some useful info:
>
>> sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> arcadia> ifort -v
> ifort version 13.0.0
This appears to be user error. According to Writing R Extensions, the
Fortran type corresponding to R logical is INTEGER, not LOGICAL.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch wrote: > > This appears to be user error. According to Writing R Extensions, the > Fortran type corresponding to R logical is INTEGER, not LOGICAL. > Oh yes, a very old and long-standing user error. I assume the CRAN checks don't check this. Has it ever been okay to pass logicals to Fortran? I shall inform the package maintainer Thanks Barry [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
On 30/09/2014 8:39 AM, Barry Rowlingson wrote: On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch mailto:murdoch.dun...@gmail.com>> wrote: This appears to be user error. According to Writing R Extensions, the Fortran type corresponding to R logical is INTEGER, not LOGICAL. Oh yes, a very old and long-standing user error. I assume the CRAN checks don't check this. The checks can't really see that kind of thing: they don't understand the external languages. It's up to the user to follow the instructions in most cases. Has it ever been okay to pass logicals to Fortran? It's okay to pass R logicals to Fortran (where they become INTEGER), it's just not okay to pass Fortran LOGICALs to R. The gcc Fortran compilers treat logicals the same as C does (i.e. 0 and 1 for FALSE and TRUE), but others don't, as you found out. Duncan Murdoch I shall inform the package maintainer Thanks Barry __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Intel Fortran compiler returns a -1 TRUE value
In S+ and S it was valid to pass logicals to .Fortran, where they got mapped into the appropriate bit pattern. (The trouble was that 'appropriate' was compiled into the program - so you were locked into our compiler vendor's choice). Passing them between Fortran code and C code has always been a problem (as has passing character data between them). Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Sep 30, 2014 at 5:39 AM, Barry Rowlingson wrote: > On Tue, Sep 30, 2014 at 12:53 PM, Duncan Murdoch > wrote: > >> >> This appears to be user error. According to Writing R Extensions, the >> Fortran type corresponding to R logical is INTEGER, not LOGICAL. >> > > Oh yes, a very old and long-standing user error. I assume the CRAN checks > don't check this. Has it ever been okay to pass logicals to Fortran? > > I shall inform the package maintainer > > Thanks > > Barry > > [[alternative HTML version deleted]] > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R's internal tar ignores files in sub-directories
E.g. I am seeing:
dir <- file.path(tempdir(), "test-tar")
dir.create(dir)
setwd(dir)
dir.create("foo", showWarnings = FALSE)
file.create("foo/bar.R")
tar("test.tar", files = "foo/bar.R")
dir.create("untarred")
untar("test.tar", exdir = "untarred")
list.files("untarred", recursive = TRUE) # character(0)
As far as I can see, the documentation in `?tar` does not reflect that
R's internal `tar` expects paths to directories, not files themselves.
Although I would have preferred the files being included, or at least
a warning / error that they would be excluded.
Thanks,
Kevin
> sessionInfo()
R version 3.1.1 Patched (2014-09-27 r66695)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] tools_3.1.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R's internal tar ignores files in sub-directories
Sounds like a bug to me, at least in documentation. I would say
that it ignores them by accident. I doubt that skipping files is
intended.
The problem appears to be that the 'files' argument to tar() becomes
the 'path' argument to list.files(), and the spec for 'path' is not
a whole lot more illuminating. Only the Description in ?list.files
refers to a _named directory_.
Your tar call blindly does list.files("foo/bar.R"), which is empty,
hence your undesired result, when it should only call list.files for
directories.
On Sep 30, 2014, at 2:14 PM, Kevin Ushey wrote:
> E.g. I am seeing:
>
>dir <- file.path(tempdir(), "test-tar")
>dir.create(dir)
>setwd(dir)
>
>dir.create("foo", showWarnings = FALSE)
>file.create("foo/bar.R")
>
>tar("test.tar", files = "foo/bar.R")
>dir.create("untarred")
>untar("test.tar", exdir = "untarred")
>list.files("untarred", recursive = TRUE) # character(0)
>
> As far as I can see, the documentation in `?tar` does not reflect that
> R's internal `tar` expects paths to directories, not files themselves.
> Although I would have preferred the files being included, or at least
> a warning / error that they would be excluded.
>
> Thanks,
> Kevin
>
>> sessionInfo()
> R version 3.1.1 Patched (2014-09-27 r66695)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
>
> locale:
> [1] LC_COLLATE=English_United States.1252
> [2] LC_CTYPE=English_United States.1252
> [3] LC_MONETARY=English_United States.1252
> [4] LC_NUMERIC=C
> [5] LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] tools_3.1.1
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Shallow copies
I have a question about shallow copies in R. Since R 3.1.0, subsetting a dataframe with respect to its columns no longer result in deep copies. This is an amazing change in my opinion. Now, subsetting a data.frame by rows (or subsetting a matrix by columns or rows) still does deep copies. In particular, it is my understanding that running a command on a very large subset of rows (say "sum" or "biglm" on non outliers observations) results in a deep copy of these rows first, which can require twice as much the memory of the original data.frame/matrix. If this is correct, I would be very interested to know more on whether this behavior can/may change in future versions of R. Thanks a lot!, Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Shallow copies
On Tue, Sep 30, 2014 at 2:20 PM, Matthieu Gomez wrote: > I have a question about shallow copies in R. Since R 3.1.0, subsetting > a dataframe with respect to its columns no longer result in deep > copies. This is an amazing change in my opinion. Now, subsetting a > data.frame by rows (or subsetting a matrix by columns or rows) still > does deep copies. In particular, it is my understanding that running a > command on a very large subset of rows (say "sum" or "biglm" on non > outliers observations) results in a deep copy of these rows first, > which can require twice as much the memory of the original > data.frame/matrix. If this is correct, I would be very interested to > know more on whether this behavior can/may change in future versions > of R. I let the experts comment on this, but subsetting/reshuffling columns in data.frame:s sound easy compared with what you're asking for. Columns of a data frame are basically just elements in a list and they don't have to be contiguous in memory whereas the elements in a matrix (of a basic data type) needs to be contiguous in memory. However, somewhat related: Having lots of these temporary copies can be quite time consuming for the garbage collector, so it's not just about the memory but also about the overall processing time. One of the next improvements in the 'matrixStats' package is to add support for specifying subsets of rows/columns to operate over - for the purpose of avoiding the auxiliary copies that you talk about, e.g. cols <- c(1:14, 87:103) rows <- seq(from=1, to=nrow(X), by=2) y <- rowMedians(X, rows=rows, columns=cols) instead of y <- rowMedians(X[rows,cols]) It's a fairly simple task to implement, but I've got lots on my plate so I don't know when this will happen. (I welcome contributions via github.com/HenrikBengtsson/matrixStats.) Similar methods in R (e.g. rowSums()) could gain from this too. /Henrik (matrixStats) PS. Code compilation could translate rowMedians(X[rows,cols]) to rowMedians(X, rows=rows, columns=cols) but that's far in the future (I think). > > Thanks a lot!, > Matthew > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
