[Rd] problem in compililng c code using R CMD SHLIB
Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\>cd \R_dir then I have given the command like this E:\>cd \R_dir> R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. Thank you [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] tcltk wish: Add tclObj.raw method for converting raw vectors to tclObj
Greetings, I have submitted a bug report / wish to the R Bug tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14939), but I'd like to make this request here as well. Essentially, I was wondering if it would be possible to add another c routine to be called by as.TclObj for raw vectors. Right now, as.raw() is supported for objects of type "tclObj" (IIRC this change was made in 2.9 after someone requested it), however there is no corresponding C routine for converting raw vectors into tclObj. I suppose the best way to do this is to create a new C routine in the tcltk package analogous to the other RObject to Tcl object routines: RTcl_ObjFromRawVector. Create a new tclObj pointer, use Tcl_NewByteArrayObj() from the Tcl C API to create a byte array of the same length as the input raw vector, and then loop through the RAWSXP object assigning each element in the vector to the Tcl byte array. I'd be happy to submit code for this patch if requested. This would be extremely helpful. I am using tcl binary sockets and this functionality would allow me to both read and write raw vectors directly from/to Tcl. I can only read raw vectors directly at the moment and have to use strings to get a raw vector into Tcl. There's also the possibility that this has been attempted and for some reason it didn't work, but I don't know why that would be the case. Thank you for your consideration! Regards, Charlie __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: > Hello all, > I was trying to compile a simple C program hello.c using R CMD SHLIB > hello.c. > MY R software residing in C:\Program Files\R\R-2.15.0, and also I have > downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in > E:\R_dir. > I have followed the procedures given below > 1. In a new CMD.exe window I have set the path as > > c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin > > 2. I have changed the directory to E:\ where my file(hello.c) is residing > E:\>cd \R_dir > then I have given the command like this > E:\>cd \R_dir> R CMD SHLIB hello.c > Then I am getting the following message > cygwin warning: > MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ > i386/Makeconf > Preferred POSIX equivalent is: > /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf > CYGWIN environment variable option "nodosfilewarning" turns off this > warning. > Consult the user's guide for more details about POSIX paths: > http://cygwin.com/cygwin-ug-net/using.html#using-pathnames > Even though I have gone through several discussions in the same topic I am > not able to resolve my problem. It would be a great help if somebody knows > what exactly the problem and its solution and favorable suggestions. There is no problem in what you posted - all you posted is merely a note from cygwin that it prefers different path style, but it's perfectly ok and doesn't affect anything. So what exactly is the problem you're having? Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stumped on re-building package vignette
[Env: Win Xp / StatET 2.0 / R 2.15.0]
In my heplots package I extended the HE-examples.Rnw vignette under
inst/doc. The package passes R CMD check
on my machine:
* using log directory 'C:/eclipse-3.7/heplots.Rcheck'
* using R version 2.15.0 (2012-03-30)
* using platform: i386-pc-mingw32 (32-bit)
...
* checking sizes of PDF files under 'inst/doc' ... OK
* checking installed files from 'inst/doc' ... OK
* checking examples ... OK
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... OK
* checking running R code from vignettes ...
'HE-examples.Rnw' ... OK
'repeated.Rnw' ... OK
...
However, on R-Forge and on CRAN, the following error/warning is generated:
Mon Jun 4 20:18:22 2012: Checking package heplots (SVN revision 136) ...
* using log directory
‘/mnt/building/build_2012-06-04-20-02/RF_PKG_CHECK/PKGS/heplots.Rcheck’
* using R version 2.15.0 Patched (2012-06-03 r59505)
* using platform: x86_64-unknown-linux-gnu (64-bit)
...
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in ‘inst/doc’ ... OK
* checking running R code from vignettes ...
‘HE-examples.Rnw’ ... [4s/4s] OK
‘repeated.Rnw’ ... [4s/4s] OK
[9s/9s] OK
* checking re-building of vignette PDFs ... NOTE
Error in re-building vignettes:
...
Loading required package: car
Loading required package: MASS
Loading required package: nnet
Error: processing vignette 'HE-examples.Rnw' failed with diagnostics:
cannot open file 'fig/plot-plastic1.pdf'
Execution halted
* checking PDF version of manual ... OK
I am unable to determine why the file fig/plot-plastic1.pdf cannot be
opened. It is in my inst/doc/fig directory & is regenerated
by the .Rnw file. What could cause this?
Second, I have tried manually running
tools::compactPDF("HE-examples.pdf) on the .pdf file under inst/doc in
the package,
but no change is made to the .pdf file. I can't see any way to correct this.
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele StreetWeb: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On Wed, Jun 6, 2012 at 8:20 AM, Simon Urbanek wrote: > > On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: > >> Hello all, >> I was trying to compile a simple C program hello.c using R CMD SHLIB >> hello.c. >> MY R software residing in C:\Program Files\R\R-2.15.0, and also I have >> downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in >> E:\R_dir. >> I have followed the procedures given below >> 1. In a new CMD.exe window I have set the path as >> >> c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin >> >> 2. I have changed the directory to E:\ where my file(hello.c) is residing >> E:\>cd \R_dir >> then I have given the command like this >> E:\>cd \R_dir> R CMD SHLIB hello.c >> Then I am getting the following message >> cygwin warning: >> MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ >> i386/Makeconf >> Preferred POSIX equivalent is: >> /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf >> CYGWIN environment variable option "nodosfilewarning" turns off this >> warning. >> Consult the user's guide for more details about POSIX paths: >> http://cygwin.com/cygwin-ug-net/using.html#using-pathnames >> Even though I have gone through several discussions in the same topic I am >> not able to resolve my problem. It would be a great help if somebody knows >> what exactly the problem and its solution and favorable suggestions. > > There is no problem in what you posted - all you posted is merely a note from > cygwin that it prefers different path style, but it's perfectly ok and > doesn't affect anything. So what exactly is the problem you're having? > Probably has something to do with PATH not being set correctly because the Cygwin warning points to R-2.14.0 on E:, not R-2.15.0 on C:. > Cheers, > Simon > Best, -- Joshua Ulrich | FOSS Trading: www.fosstrading.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem in compililng c code using R CMD SHLIB
On 06/06/2012 18:12, Joshua Ulrich wrote: On Wed, Jun 6, 2012 at 8:20 AM, Simon Urbanek wrote: On Jun 6, 2012, at 6:16 AM, Arathy Ram wrote: Hello all, I was trying to compile a simple C program hello.c using R CMD SHLIB hello.c. MY R software residing in C:\Program Files\R\R-2.15.0, and also I have downloaded the Rtools 2.15.0 and it is in C:\Rtools, MY file(hello.c) is in E:\R_dir. I have followed the procedures given below 1. In a new CMD.exe window I have set the path as c:\ Rtools\bin; C:\Rtools\MinGW\bin;C:\Program Files\R\R-2.15.0\bin 2. I have changed the directory to E:\ where my file(hello.c) is residing E:\>cd \R_dir then I have given the command like this E:\>cd \R_dir> R CMD SHLIB hello.c Then I am getting the following message cygwin warning: MS-DOS style path detected: E:/PROGRA~1/R/R-214~1.0/etc/ i386/Makeconf Preferred POSIX equivalent is: /cygdrive/e/PROGRA~1/R/R-214~1.0/etc/i386/Makeconf CYGWIN environment variable option "nodosfilewarning" turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames Even though I have gone through several discussions in the same topic I am not able to resolve my problem. It would be a great help if somebody knows what exactly the problem and its solution and favorable suggestions. There is no problem in what you posted - all you posted is merely a note from cygwin that it prefers different path style, but it's perfectly ok and doesn't affect anything. Or put another way, the problem is a user read failure: see below. >> So what exactly is the problem you're having? Probably has something to do with PATH not being set correctly because the Cygwin warning points to R-2.14.0 on E:, not R-2.15.0 on C:. But as for the note, it *is* discussed in the appropriate manual. Search for 'nodosfilewarning' in http://cran.r-project.org/doc/manuals/R-admin.html#The-command-line-tools . You most likely will need to set that environment variable. See what the posting guide has to say about doing your own homework. fortunes::fortune(14) applies. The author of the docs you discourteously ignored (and much else you are using). -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 7 arguments passed to .Internal(identical) which requires 6
Dan Tenenbaum fhcrc.org> writes: > > I know this has come up before on R-help > (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- requires-6-td4548460.html) > but I have a concise reproducible case that I wanted to share. > > Also, please note the Bioconductor scenario which is potentially > seriously impacted by this. > The issue arises when a binary version of a package (like my example > package below) is built under R 2.15.0 Patched but then installed > under R 2.15.0. Our package AnnotationDbi (which hundreds of other > packages depend on) is impacted by this issue to the extent that > calling virtually any function in it will return something like this: > Error in ls(2) : > 7 arguments passed to .Internal(identical) which requires 6 > > My concern is that when R 2.15.1 is released and Bioconductor starts > building all its packages under it, that R 2.15.0 users will start to > experience this problem. We can ask all users to upgrade to R 2.15.1 > if we have to, but it's not usually the case that a minor point > release MUST be installed in order to run packages built under it > (please correct me if I'm wrong). We would much prefer a workaround or > fix to make an upgrade unnecessary. > I'm seeing the same issue. Installing the latest R-Forge .zip of data.table built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running data.table(a=1:3) produces the "7 arguments passed to .Internal(identical) which requires 6" error. traceback() and debugger() just display the top level call. debug(data.table) and stepping through reveals it is a call to identical () but just a regular one. No .Internal() call in the package, let alone passing 6 or 7 arguments to .Internal. Not sure how else to debug or trace it. R-Forge is byte compiling data.table using R 2.15.0 patched (iiuc), would that make a difference when the byte code is loaded into 2.15.0 which doesn't have the new argument in identical()? Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 7 arguments passed to .Internal(identical) which requires 6
On Wed, 6 Jun 2012, Matthew Dowle wrote: Dan Tenenbaum fhcrc.org> writes: I know this has come up before on R-help (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- requires-6-td4548460.html) but I have a concise reproducible case that I wanted to share. Also, please note the Bioconductor scenario which is potentially seriously impacted by this. The issue arises when a binary version of a package (like my example package below) is built under R 2.15.0 Patched but then installed under R 2.15.0. Our package AnnotationDbi (which hundreds of other packages depend on) is impacted by this issue to the extent that calling virtually any function in it will return something like this: Error in ls(2) : 7 arguments passed to .Internal(identical) which requires 6 My concern is that when R 2.15.1 is released and Bioconductor starts building all its packages under it, that R 2.15.0 users will start to experience this problem. We can ask all users to upgrade to R 2.15.1 if we have to, but it's not usually the case that a minor point release MUST be installed in order to run packages built under it (please correct me if I'm wrong). We would much prefer a workaround or fix to make an upgrade unnecessary. I'm seeing the same issue. Installing the latest R-Forge .zip of data.table built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running data.table(a=1:3) produces the "7 arguments passed to .Internal(identical) which requires 6" error. traceback() and debugger() just display the top level call. debug(data.table) and stepping through reveals it is a call to identical () but just a regular one. No .Internal() call in the package, let alone passing 6 or 7 arguments to .Internal. Not sure how else to debug or trace it. R-Forge is byte compiling data.table using R 2.15.0 patched (iiuc), would that make a difference when the byte code is loaded into 2.15.0 which doesn't have the new argument in identical()? Yes it would. luke Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Luke Tierney Chair, Statistics and Actuarial Science Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics andFax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tier...@uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 7 arguments passed to .Internal(identical) which requires 6
FYI, Brian has backed out the changes to identical() in r59533 of R-patched. Please retry your test codes with the new version. (Due to some ISP mess-up, Brian is temporarily unable to reply in detail himself.) -pd On Jun 6, 2012, at 20:29 , wrote: > On Wed, 6 Jun 2012, Matthew Dowle wrote: > >> Dan Tenenbaum fhcrc.org> writes: >> >>> >>> I know this has come up before on R-help >>> (http://r.789695.n4.nabble.com/7-arguments-passed-to-Internal-identical-which- >> requires-6-td4548460.html) >>> but I have a concise reproducible case that I wanted to share. >>> >>> Also, please note the Bioconductor scenario which is potentially >>> seriously impacted by this. >>> The issue arises when a binary version of a package (like my example >>> package below) is built under R 2.15.0 Patched but then installed >>> under R 2.15.0. Our package AnnotationDbi (which hundreds of other >>> packages depend on) is impacted by this issue to the extent that >>> calling virtually any function in it will return something like this: >>> Error in ls(2) : >>> 7 arguments passed to .Internal(identical) which requires 6 >>> >>> My concern is that when R 2.15.1 is released and Bioconductor starts >>> building all its packages under it, that R 2.15.0 users will start to >>> experience this problem. We can ask all users to upgrade to R 2.15.1 >>> if we have to, but it's not usually the case that a minor point >>> release MUST be installed in order to run packages built under it >>> (please correct me if I'm wrong). We would much prefer a workaround or >>> fix to make an upgrade unnecessary. >>> >> >> I'm seeing the same issue. Installing the latest R-Forge .zip of data.table >> built using 2.15.0 patched, on R 2.15.0 (or 2.14.1 same issue), then running >> data.table(a=1:3) produces the "7 arguments passed to .Internal(identical) >> which requires 6" error. traceback() and debugger() just display the top >> level >> call. debug(data.table) and stepping through reveals it is a call to >> identical >> () but just a regular one. No .Internal() call in the package, let alone >> passing 6 or 7 arguments to .Internal. >> >> Not sure how else to debug or trace it. R-Forge is byte compiling data.table >> using R 2.15.0 patched (iiuc), would that make a difference when the byte >> code >> is loaded into 2.15.0 which doesn't have the new argument in identical()? > > Yes it would. > > luke > >> >> Matthew >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Luke Tierney > Chair, Statistics and Actuarial Science > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics andFax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] suggest that as.double( something double ) not make a copy
I've been playing with passing arguments to .C(), and found that replacing as.double(x) with if(is.double(x)) x else as.double(x) saves time and avoids one copy, in the case that x is already double. I suggest modifying as.double to avoid the extra copy and just return x, when x is already double. Similarly for as.integer, etc. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
On Jun 6, 2012, at 6:53 PM, Tim Hesterberg wrote:
> I've been playing with passing arguments to .C(), and found that replacing
>as.double(x)
> with
>if(is.double(x)) x else as.double(x)
> saves time and avoids one copy, in the case that x is already double.
>
No, it doesn't:
> x=rnorm(10)
> tracemem(x)
[1] "<0x100c59cb0>"
> invisible(.C("foo",x))
tracemem[0x100c59cb0 -> 0x100c59c30]: .C
tracemem[0x100c59c30 -> 0x100ca4298]: .C
> x=rnorm(10)
> tracemem(x)
[1] "<0x100ca41f0>"
> invisible(.C("foo",as.double(x)))
tracemem[0x100ca41f0 -> 0x102cdc980]: .C
tracemem[0x102cdc980 -> 0x102cdca00]: .C
or rather more easily:
> x=rnorm(10)
> tracemem(x)
[1] "<0x102ae0ff0>"
> as.double(x)
[1] -0.1027767 0.4018732 -1.3412045 0.8153615 1.8245356 -0.2147280
[7] 1.1298404 1.1026897 -1.1340612 -0.2346464
as.double(x) is not stupid and doesn't copy if not needed.
However, it is a very common mistake to forget about the fact that as.double()
has to strip attributes, so if you pass a matrix, you are always forcing a copy:
> x=matrix(0,2,2)
> tracemem(x)
[1] "<0x100b0f098>"
> as.double(x)
tracemem[0x100b0f098 -> 0x1008b52c8]:
[1] 0 0 0 0
That is not the fault of as.double() but rather of the user since you don't
really need to strip attributes when calling .C as it doesn't care.
As usual, I can only say don't use .C() ... ;)
Cheers,
Simon
> I suggest modifying as.double to avoid the extra copy and just
> return x, when x is already double. Similarly for as.integer, etc.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
Tim Hesterberg gmail.com> writes:
> I've been playing with passing arguments to .C(), and found that replacing
> as.double(x)
> with
> if(is.double(x)) x else as.double(x)
> saves time and avoids one copy, in the case that x is already double.
>
> I suggest modifying as.double to avoid the extra copy and just
> return x, when x is already double. Similarly for as.integer, etc.
>
But as.double() already doesn't copy if its argument is already double. Unless,
your double has attributes?
>From coerce.c :
if(TYPEOF(x) == type) {
if(ATTRIB(x) == R_NilValue) return x;
ans = NAMED(x) ? duplicate(x) : x;
CLEAR_ATTRIB(ans);
return ans;
}
quick test :
> x=1
> .Internal(inspect(x))
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
> .Internal(inspect(as.double(x))) # no copy
@03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
> x=c(foo=1) # give x some attributes, say names
> x
foo
1
> .Internal(inspect(x))
@03E234D0 14 REALSXP g0c1 [NAM(1),ATT] (len=1, tl=0) 1
ATTRIB:
@03D54910 02 LISTSXP g0c0 []
TAG: @00380088 01 SYMSXP g0c0 [MARK,gp=0x4000] "names"
@03E234A0 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
@03E23560 09 CHARSXP g0c1 [gp=0x21] "foo"
> .Internal(inspect(as.double(x))) # strips attribs returning new obj
@03E233B0 14 REALSXP g0c1 [] (len=1, tl=0) 1
> as.double(x)
[1] 1
>
Attribute stripping is documented in ?as.double. Rather than as.double() on the
R side, you could use coerceVector() on the C side, which might be easier to
use via .Call than .C since it takes an SEXP. Looking at coerceVector in
coerce.c its first line returns immediately if type is already the desired
type, with no attribute stripping, so that seems like the way to go?
If your double has no attributes then I'm barking up the wrong tree.
Matthew
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggest that as.double( something double ) not make a copy
Check if this is the same as what was done in R v2.6.0 (2007) - from
http://cran.r-project.org/bin/windows/base/old/2.6.0/NEWS.R-2.6.0:
o as.vector() and the default methods of as.character(),
as.complex(), as.double(), as.expression(), as.integer(),
as.logical() and as.raw() no longer duplicate in most cases
where the object is unchanged. (Beware: some code has been
written that invalidly assumes that they do duplicate, often
when using .C/.Fortran(DUP=FALSE).)
See also R-devel '[Rd] Suggestion for memory optimization and
as.double() with friends', March 28-29 2007
[https://stat.ethz.ch/pipermail/r-devel/2007-March/045109.html].
/Henrik
On Wed, Jun 6, 2012 at 6:12 PM, Matthew Dowle wrote:
> Tim Hesterberg gmail.com> writes:
>
>> I've been playing with passing arguments to .C(), and found that replacing
>> as.double(x)
>> with
>> if(is.double(x)) x else as.double(x)
>> saves time and avoids one copy, in the case that x is already double.
>>
>> I suggest modifying as.double to avoid the extra copy and just
>> return x, when x is already double. Similarly for as.integer, etc.
>>
>
> But as.double() already doesn't copy if its argument is already double.
> Unless,
> your double has attributes?
>
> >From coerce.c :
>
> if(TYPEOF(x) == type) {
> if(ATTRIB(x) == R_NilValue) return x;
> ans = NAMED(x) ? duplicate(x) : x;
> CLEAR_ATTRIB(ans);
> return ans;
> }
>
> quick test :
>
>> x=1
>> .Internal(inspect(x))
> @03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
>> .Internal(inspect(as.double(x))) # no copy
> @03E23620 14 REALSXP g0c1 [NAM(2)] (len=1, tl=0) 1
>> x=c(foo=1) # give x some attributes, say names
>> x
> foo
> 1
>> .Internal(inspect(x))
> @03E234D0 14 REALSXP g0c1 [NAM(1),ATT] (len=1, tl=0) 1
> ATTRIB:
> @03D54910 02 LISTSXP g0c0 []
> TAG: @00380088 01 SYMSXP g0c0 [MARK,gp=0x4000] "names"
> @03E234A0 16 STRSXP g0c1 [NAM(2)] (len=1, tl=0)
> @03E23560 09 CHARSXP g0c1 [gp=0x21] "foo"
>> .Internal(inspect(as.double(x))) # strips attribs returning new obj
> @03E233B0 14 REALSXP g0c1 [] (len=1, tl=0) 1
>> as.double(x)
> [1] 1
>>
>
> Attribute stripping is documented in ?as.double. Rather than as.double() on
> the
> R side, you could use coerceVector() on the C side, which might be easier to
> use via .Call than .C since it takes an SEXP. Looking at coerceVector in
> coerce.c its first line returns immediately if type is already the desired
> type, with no attribute stripping, so that seems like the way to go?
>
> If your double has no attributes then I'm barking up the wrong tree.
>
> 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
