Re: [Rd] memory allocation if multiple names point to the same object
This is because R keeps track of the names of an object, until there are 2
names. Thus, once it reaches 2, it can no longer decrement the named count.
In this example, 'a' reaches 2 names ('a' and 'b'), thus R does not know
that 'a' only has one name at the end.
Luke has added reference counting to R 3.1 to get around these types of
problems. If you want to try it out, make the necessary change in
Rinternals.h and recompile. With reference counting, R knows that 'a' only
has one reference and avoids the copy.
> a <- seq.int(10)
> a[1:4] <- 4:1
> b <- a
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(2)] (len=10, tl=0) 4,3,2,1,5,...
> b[1:4] <- 1:4
> .Internal(inspect(b))
@2b715a0 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 1,2,3,4,5,...
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 4,3,2,1,5,...
> a[1:4] <- 1:4
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 1,2,3,4,5,...
On Mon, Jun 2, 2014 at 9:31 AM, Dénes Tóth wrote:
>
> Hi,
>
> Please consider the following code:
>
> a <- seq.int(10) # create a
> tracemem(a)
> a[1:4] <- 4:1 # no internal copy
> b <- a # no internal copy
> b[1:4] <- 1:4 # copy, b is not a any more
> a[1:4] <- 1:4 # copy, but why?
>
> With results:
> > a <- seq.int(10)
> > tracemem(a)
> [1] "<0x1792bc0>"
> > a[1:4] <- 4:1
> > b <- a
> > b[1:4] <- 1:4
> tracemem[0x1792bc0 -> 0x1792b58]:
> > a[1:4] <- 1:4
> tracemem[0x1792bc0 -> 0x1792af0]:
>
>
> ##
>
> Could you provide a brief explanation or point me to a source why R needs
> a copy in the final step?
>
>
> Best,
> Denes
>
>
>
> > sessionInfo()
> R version 3.1.0 (2014-04-10)
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> locale:
> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] setting environmental variable inside R function to call C function
wrapper <- function(){
Sys.setenv(TMP="A")
print(Sys.getenv("TMP"))
.C("c_fun")
}
As the example above, I hope to set an env var $TMP inside the R function
"wrapper", which affects the functionality of the C function call "c_fun".
Also the print line shows that $TMP is set to be "A", but the function call
of "c_fun" was not affected.
Does anyone know why and how to correctly set the env var for subsequent
functions?
Thanks,
BW
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setting environmental variable inside R function to call C function
What does c_fun look like? Here's mine:
#include
#include
void c_fun(){
printf("TMP is %s\n", getenv("TMP"));
}
and I then do this at the shell prompt:
R CMD SHLIB c_fun.c
and this at the R prompt:
dyn.load("c_fun.so")
wrapper()
and I get:
> wrapper()
[1] "A"
TMP is A
list()
Is that not what you want?
tldr; works for me.
On Tue, Jun 3, 2014 at 5:55 PM, Bowen Meng wrote:
> wrapper <- function(){
> Sys.setenv(TMP="A")
> print(Sys.getenv("TMP"))
>
> .C("c_fun")
> }
>
>
> As the example above, I hope to set an env var $TMP inside the R function
> "wrapper", which affects the functionality of the C function call "c_fun".
> Also the print line shows that $TMP is set to be "A", but the function call
> of "c_fun" was not affected.
>
> Does anyone know why and how to correctly set the env var for subsequent
> functions?
>
> Thanks,
> BW
>
> [[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
Re: [Rd] setting environmental variable inside R function to call C function
I suspect the intend is to send a value from R to compiled code. Which
happens to be a problem for which Rcpp offers a pretty convenient solution.
And if you really, really want to, you can even program in C inside of an
Rcpp interface:
R> cppFunction("int foo(std::string txt) { Rprintf(\"Var is %s\\n\",
txt.c_str()); return 0; }")
R> foo("A")
Var is A
[1] 0
R>
Dirk
On 3 June 2014 at 19:06, Barry Rowlingson wrote:
| What does c_fun look like? Here's mine:
|
| #include
| #include
| void c_fun(){
| printf("TMP is %s\n", getenv("TMP"));
| }
|
| and I then do this at the shell prompt:
|
| R CMD SHLIB c_fun.c
|
| and this at the R prompt:
|
| dyn.load("c_fun.so")
| wrapper()
|
| and I get:
|
| > wrapper()
| [1] "A"
| TMP is A
| list()
|
| Is that not what you want?
|
| tldr; works for me.
|
|
| On Tue, Jun 3, 2014 at 5:55 PM, Bowen Meng wrote:
| > wrapper <- function(){
| > Sys.setenv(TMP="A")
| > print(Sys.getenv("TMP"))
| >
| > .C("c_fun")
| > }
| >
| >
| > As the example above, I hope to set an env var $TMP inside the R function
| > "wrapper", which affects the functionality of the C function call "c_fun".
| > Also the print line shows that $TMP is set to be "A", but the function call
| > of "c_fun" was not affected.
| >
| > Does anyone know why and how to correctly set the env var for subsequent
| > functions?
| >
| > Thanks,
| > BW
| >
| > [[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
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] A bug in princomp(), perhaps?
Thank you, Ben.
Best,
Ravi
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Ben Bolker
Sent: Monday, June 02, 2014 8:07 PM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] A bug in princomp(), perhaps?
Ben Bolker gmail.com> writes:
>
> FWIW this seems to be a FAQ:
>
> https://stat.ethz.ch/pipermail/r-devel/2003-July/027018.html
>
> http://thr3ads.net/r-devel/2013/01/
>2171832-Re-na.omit-option-in-prcomp-formula-interface-only
>
> http://r.789695.n4.nabble.com/
> na-omit-option-in-prcomp-formula-interface-only-td4373533.html
>
> And two StackOverflow questions (the latter's a bit tangential):
>
> http://stackoverflow.com/questions/12078291/
>r-function-prcomp-fails-with-nas-values-even-though-nas-are-allowed
>
> http://stackoverflow.com/questions/23421438/
> what-was-wrong-with-running-princomp-in-r/23446938#23446938
>
> (Sorry for broken URLs and random assortment of mailing list
> aggregators.)
>
> I appreciate Gavin's points that implementing this stuff for
> princomp.default is difficult/problematic, but I second Ravi's request
> for a little more clarification in the help text; it's quite easy to
> miss the fact that 'na.action' is defined for princomp.formula but not
> for princomp.default. Perhaps just "Note that setting na.action works
> for princomp.formula, but not for princomp.default" (under the
> "na.action" argument description).
Putting my effort where my mouth is: I wonder if there is any chance that this
patch against the current SVN would be accepted ... ??
Index: princomp.Rd
===
--- princomp.Rd (revision 65832)
+++ princomp.Rd (working copy)
@@ -37,7 +37,8 @@
when the data contain \code{NA}s. The default is set by
the \code{na.action} setting of \code{\link{options}}, and is
\code{\link{na.fail}} if that is unset. The \sQuote{factory-fresh}
-default is \code{\link{na.omit}}.}
+default is \code{\link{na.omit}}. (This argument applies \emph{only}
+to the formula method.)}
\item{x}{a numeric matrix or data frame which provides the data for the
principal components analysis.}
\item{cor}{a logical value indicating whether the calculation should
Index: prcomp.Rd
===
--- prcomp.Rd (revision 65832)
+++ prcomp.Rd (working copy)
@@ -40,7 +40,8 @@
when the data contain \code{NA}s. The default is set by
the \code{na.action} setting of \code{\link{options}}, and is
\code{\link{na.fail}} if that is unset. The \sQuote{factory-fresh}
-default is \code{\link{na.omit}}.}
+default is \code{\link{na.omit}}. (This argument applies \emph{only}
+to the formula method.)}
\item{\dots}{arguments passed to or from other methods. If \code{x} is
a formula one might specify \code{scale.} or \code{tol}.}
\item{x}{a numeric or complex matrix (or data frame) which provides
__
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
Re: [Rd] A bug in princomp(), perhaps?
Perhaps, adding Gavin's work around for a dataframe with missing values might
also be useful to the documentation:
princomp(na.omit(x))
Thanks,
Ravi
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Ben Bolker
Sent: Monday, June 02, 2014 8:07 PM
To: r-de...@stat.math.ethz.ch
Subject: Re: [Rd] A bug in princomp(), perhaps?
Ben Bolker gmail.com> writes:
>
> FWIW this seems to be a FAQ:
>
> https://stat.ethz.ch/pipermail/r-devel/2003-July/027018.html
>
> http://thr3ads.net/r-devel/2013/01/
>2171832-Re-na.omit-option-in-prcomp-formula-interface-only
>
> http://r.789695.n4.nabble.com/
> na-omit-option-in-prcomp-formula-interface-only-td4373533.html
>
> And two StackOverflow questions (the latter's a bit tangential):
>
> http://stackoverflow.com/questions/12078291/
>r-function-prcomp-fails-with-nas-values-even-though-nas-are-allowed
>
> http://stackoverflow.com/questions/23421438/
> what-was-wrong-with-running-princomp-in-r/23446938#23446938
>
> (Sorry for broken URLs and random assortment of mailing list
> aggregators.)
>
> I appreciate Gavin's points that implementing this stuff for
> princomp.default is difficult/problematic, but I second Ravi's request
> for a little more clarification in the help text; it's quite easy to
> miss the fact that 'na.action' is defined for princomp.formula but not
> for princomp.default. Perhaps just "Note that setting na.action works
> for princomp.formula, but not for princomp.default" (under the
> "na.action" argument description).
Putting my effort where my mouth is: I wonder if there is any chance that this
patch against the current SVN would be accepted ... ??
Index: princomp.Rd
===
--- princomp.Rd (revision 65832)
+++ princomp.Rd (working copy)
@@ -37,7 +37,8 @@
when the data contain \code{NA}s. The default is set by
the \code{na.action} setting of \code{\link{options}}, and is
\code{\link{na.fail}} if that is unset. The \sQuote{factory-fresh}
-default is \code{\link{na.omit}}.}
+default is \code{\link{na.omit}}. (This argument applies \emph{only}
+to the formula method.)}
\item{x}{a numeric matrix or data frame which provides the data for the
principal components analysis.}
\item{cor}{a logical value indicating whether the calculation should
Index: prcomp.Rd
===
--- prcomp.Rd (revision 65832)
+++ prcomp.Rd (working copy)
@@ -40,7 +40,8 @@
when the data contain \code{NA}s. The default is set by
the \code{na.action} setting of \code{\link{options}}, and is
\code{\link{na.fail}} if that is unset. The \sQuote{factory-fresh}
-default is \code{\link{na.omit}}.}
+default is \code{\link{na.omit}}. (This argument applies \emph{only}
+to the formula method.)}
\item{\dots}{arguments passed to or from other methods. If \code{x} is
a formula one might specify \code{scale.} or \code{tol}.}
\item{x}{a numeric or complex matrix (or data frame) which provides
__
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] cuda-memcheck to debug CUDA-enabled R packages
I'm building a simple R extension around a CUDA-enabled dynamic library, and
I want to run the whole package with cuda-memcheck for debugging purposes. I
can run it just fine with Valgrind:
$ R --no-save -d valgrind < test.R
However, if I try the same thing with cuda-memcheck,
$ R --no-save -d cuda-memcheck < test.R
I get:
*** Further command line arguments ('--no-save ') disregarded
*** (maybe use 'run --no-save ' from *inside* cuda-memcheck)
= CUDA-MEMCHECK
Fatal error: you must specify '--save', '--no-save' or '--vanilla'
= No CUDA-MEMCHECK results found
So cuda-memcheck is eating up an argument that's supposed to go to R. What
can I do about this?
--
View this message in context:
http://r.789695.n4.nabble.com/cuda-memcheck-to-debug-CUDA-enabled-R-packages-tp4691668.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] memory allocation if multiple names point to the same object
Dear Michael,
thank you for the enlightenment. Just for the records, here is the
solution that Michael referred to:
http://developer.r-project.org/Refcnt.html
Best,
Denes
On 06/03/2014 03:57 PM, Michael Lawrence wrote:
This is because R keeps track of the names of an object, until there are
2 names. Thus, once it reaches 2, it can no longer decrement the named
count. In this example, 'a' reaches 2 names ('a' and 'b'), thus R does
not know that 'a' only has one name at the end.
Luke has added reference counting to R 3.1 to get around these types of
problems. If you want to try it out, make the necessary change in
Rinternals.h and recompile. With reference counting, R knows that 'a'
only has one reference and avoids the copy.
> a <- seq.int (10)
> a[1:4] <- 4:1
> b <- a
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(2)] (len=10, tl=0) 4,3,2,1,5,...
> b[1:4] <- 1:4
> .Internal(inspect(b))
@2b715a0 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 1,2,3,4,5,...
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 4,3,2,1,5,...
> a[1:4] <- 1:4
> .Internal(inspect(a))
@2b71608 13 INTSXP g0c4 [REF(1)] (len=10, tl=0) 1,2,3,4,5,...
On Mon, Jun 2, 2014 at 9:31 AM, Dénes Tóth mailto:toth.de...@ttk.mta.hu>> wrote:
Hi,
Please consider the following code:
a <- seq.int (10) # create a
tracemem(a)
a[1:4] <- 4:1 # no internal copy
b <- a # no internal copy
b[1:4] <- 1:4 # copy, b is not a any more
a[1:4] <- 1:4 # copy, but why?
With results:
> a <- seq.int (10)
> tracemem(a)
[1] "<0x1792bc0>"
> a[1:4] <- 4:1
> b <- a
> b[1:4] <- 1:4
tracemem[0x1792bc0 -> 0x1792b58]:
> a[1:4] <- 1:4
tracemem[0x1792bc0 -> 0x1792af0]:
##
Could you provide a brief explanation or point me to a source why R
needs a copy in the final step?
Best,
Denes
> sessionInfo()
R version 3.1.0 (2014-04-10)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
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
