[Rd] problem with replicate and "..." (PR#8472)
I am using R version 2.0.0 (2004-10-04) on Fedora Core 2.
This works correctly:
> foo <- function(x=1,y=2) { c(x,y) }
> bar <- function(n,...) c(n,foo(...))
> bar(10,3)
[1] 10 3 2
But it goes wrong if I replace "c" in bar with "replicate":
> foo <- function(x=1,y=2) { c(x,y) }
> bar <- function(n,...) replicate(n,foo(...))
> bar(10,3)
[,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
[1,]000000000 0
[2,]222222222 2
It is mysterious why x was bound to the apparently arbitrary
value 0 while y was left at its default.
The ... arguments to bar seems to be ignored altogether.
bar(10), bar(10,x=3), and bar(10,3,4) give the same result.
Furthermore, bar(10,extra=3) does not give an error.
Perhaps this mysterious behavior is unavoidable because of
the kind of hack replicate is?
Thanks ...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with replicate and "..." (PR#8473)
p.s. Note that one workaround is
> bar <- function(n,...) { f <- function() foo(...);
+ replicate(n,f()) }
> bar(10,3)
[,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
[1,]333333333 3
[2,]222222222 2
A little while ago, Jason Eisner wrote:
> I am using R version 2.0.0 (2004-10-04) on Fedora Core 2.
>
> This works correctly:
>
>> foo <- function(x=1,y=2) { c(x,y) }
>> bar <- function(n,...) c(n,foo(...))
>> bar(10,3)
> [1] 10 3 2
>
> But it goes wrong if I replace "c" in bar with "replicate":
>
>> foo <- function(x=1,y=2) { c(x,y) }
>> bar <- function(n,...) replicate(n,foo(...))
>> bar(10,3)
> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
> [1,]000000000 0
> [2,]222222222 2
>
> It is mysterious why x was bound to the apparently arbitrary
> value 0 while y was left at its default.
>
> The ... arguments to bar seems to be ignored altogether.
> bar(10), bar(10,x=3), and bar(10,3,4) give the same result.
> Furthermore, bar(10,extra=3) does not give an error.
>
> Perhaps this mysterious behavior is unavoidable because of
> the kind of hack replicate is?
>
> Thanks ...
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [rfc] Package to access the internal zlib library.
To make R.matlab's readMat work for me[1] I needed access to zlib's uncompress function. R already links with zlib, and sometime last year I hobbled together a quick package to get at a few functions. It's my first package, so I would love feedback both on the package and its purpose. I've dropped a temporary copy at http://jriedy.users.sonic.net/internalzlib_0.1.tar.gz Could someone with Windows and knowledge of how to decypher Windows problems test if it works for them? I still need to try AIX as well. Jason Footnotes: [1] I'm cleaning patches to send to the author shortly. I think I have readMat working for compressed data, UTF-*, and sparse matrices now. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [rfc] Package to access the internal zlib library.
And Duncan Temple Lang writes: > This deals with various compression schemes and does things in > memory. Hopefully there isn't much overlap and the two might > be complementary. Rcompression provides what's necessary for R.matlab's readMat. I'll switch to using it instead. What would it take to move Rcompression into CRAN? Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [rfc] Package to access the internal zlib library.
And Brian Ripley writes: > The *only* safe thing to do is to include your own copy of > zlib, and compile it into the package (optionally linking > instead to the system copy if it exists). Fair enough, and likely necessary on AIX with XCOFF's restrictions. The Rcompression package mentioned by Duncan Lang has most of what I need, so I should help with Rcompression instead. > Please note that Uwe Ligges provides a Windows testing service: > see 'Writing R Extensions' and the R-admin manual. You don't > need to ask others to do this for you. Great! Thank you and Uwe Ligges! I completely missed the "Services" section. Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] problem with replicate and "..." (PR#8472)
Yesterday morning, Peter Dalgaard wrote:
> [EMAIL PROTECTED] writes:
>
>> I am using R version 2.0.0 (2004-10-04) on Fedora Core 2.
>>
>> This works correctly:
>>
>> > foo <- function(x=1,y=2) { c(x,y) }
>> > bar <- function(n,...) c(n,foo(...))
>> > bar(10,3)
>> [1] 10 3 2
>>
>> But it goes wrong if I replace "c" in bar with "replicate":
>>
>> > foo <- function(x=1,y=2) { c(x,y) }
>> > bar <- function(n,...) replicate(n,foo(...))
>> > bar(10,3)
>> [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10]
>> [1,]000000000 0
>> [2,]222222222 2
>>
>> It is mysterious why x was bound to the apparently arbitrary
>> value 0 while y was left at its default.
>>
>> The ... arguments to bar seems to be ignored altogether.
>> bar(10), bar(10,x=3), and bar(10,3,4) give the same result.
>> Furthermore, bar(10,extra=3) does not give an error.
>>
>> Perhaps this mysterious behavior is unavoidable because of
>> the kind of hack replicate is?
>
> Yes. It is really a wrapper for
>
> sapply(integer(n), eval.parent(substitute(function(...) expr))
>
> Now, integer(n) is n zeroes, and the function that is passed to sapply
> is
>
> Browse[1]> FUN
> function (...)
> foo(...)
>
>
> Now, this gets called as FUN(0) and in turn foo(0) which is c(0,2).
>
> So, the short answer is "don't do that", and the long answer is "don't
> do that". If you're adventurous, you could try experimenting with a
> different definition, possibly
>
> sapply(integer(n), eval.parent(substitute(function(...) eval.parent(expr)))
>
> but I'm far from sure that it works...
Peter: thanks for the good explanation.
Perhaps the OFFICIAL replicate function can be fixed as you suggest
above, or by somehow incorporating this workaround:
bar <- function(n,...) { f <- function() foo(...);
replicate(n,f()) }
If not, then may I suggest that help("replicate") should document the
limitation, and perhaps the workaround as well?
(The help page does mention that replicate is just a convenience
wrapper, but without a BUGS or LIMITATIONS section as on Unix
manpages, a user might be forgiven for assuming that it actually works
in all cases. Obviously, a user shouldn't have to understand how a
function is implemented in order to avoid nasty special cases.)
Thanks! -jason
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Understanding the sequence of events when calling the R dpois function
Hello all, I am trying to get a better understanding of the underlying code for the stats::dpois function in R and, specifically, what happens under the hood when it is called. I finally managed to track down the C course at: https://github.com/wch/r-source/blob/trunk/src/nmath/dpois.c. It would seem that the dpois C function is taking a double for each of the x and lambda arguments so I am a bit confused why I can provide a vector and matrix to dpois in R, e.g. dpois(1:5, matrix(runif(2*5, 1, 10), nrow = 5))) and get a matrix back with the results. Due to this, I was expecting to see a loop, or similar, in the underlying C source but… to no avail. So I have to conclude that either a) there is a step between when I call dpois in R and the C code getting executed that loops over the inputs or b) that there is a construct in the C code (my proficiency here is limited) that is called per input. Any help in enlightening me on what code is responsible for iterating over the multiple inputs (or if someone is feeling energetic, the exact stepwise code that is executed when calling dpois) would be greatly appreciated!! Kind Regards, Jason Serviss [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Understanding the sequence of events when calling the R dpois function
Chuck and Greg,
Thanks a lot for your help! I have a much better understanding now of what is
happening “under the hood”.
Kind Regards,
Jason
> On 31 May 2018, at 20:08, Greg Minshall wrote:
>
> Jason,
>
> as Chuck Berry (to whom, *thanks* for 'do {...} while(0)'!) suggested,
> using grep, or even grep executed from find, such as
>
> find . -type f -exec grep -H "dpois" \{\} \; | less
>
> (executed from the root of an R source tree), is your friend.
>
> cheers, Greg
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Making R CMD nicer
Hello everyone, First time posting in the R mailing lists so hopefully this works well. I noticed when I type `R CMD` I get this unhelpful message: /usr/lib/R/bin/Rcmd: 60: shift: can't shift that many This probably comes from the file Rcmd.in. This should be easily fixed by checking $#. I also think it would be nice if `R CMD help` showed the usable commands. In fact I think the CMD syntax is unnecessary since the man page shows using R with an infile or outfile must use redirection, so the syntax can be simply "R install" (like in git). Thanks, Jason [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Making R CMD nicer
In my humble personal opinion, I try to avoid bash scripts longer than a couple lines because I find the syntax so obtuse and unintuitive it's difficult to maintain and write less buggy code. But that is mostly a reflection of my personal inexperience. I think the only time a bash script is really needed is for maximum portability in systems _with bash_. (I would use python for a wrapper in personal projects, given python comes pre-installed on many linux systems and OS X, but I completely understand not wanting to burden Windows users with an extra python dependency to install.) On Sun, Jun 30, 2019 at 8:08 PM Abby Spurdle wrote: > In that case, I was wrong. > And I must apologize... > > In saying that, good to see Windows out performing Linux on the command > line... > > > On Mon, Jul 1, 2019 at 11:30 AM Gábor Csárdi > wrote: > > > > For the record, this is Linux R-devel: > > > > root@4bef68c16864:~# R CMD > > /opt/R-devel/lib/R/bin/Rcmd: 60: shift: can't shift that many > > root@4bef68c16864:~# R CMD -h > > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: -h: not found > > root@4bef68c16864:~# R CMD --help > > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: --help: not found > > > > This is R-release on macOS: > > > > ❯ R CMD > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: > > /Library/Frameworks/R.framework/Resources/bin/: is a directory > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: > > /Library/Frameworks/R.framework/Resources/bin/: cannot execute: > > Undefined error: 0 > > ❯ R CMD -h > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: -h: > > invalid option > > exec: usage: exec [-cl] [-a name] file [redirection ...] > > ❯ R CMD --help > > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: --: > > invalid option > > exec: usage: exec [-cl] [-a name] file [redirection ...] > > > > On Windows you indeed get a useful list of commands and more helpful > tips. > > > > Gabor > > > > > > On Sun, Jun 30, 2019 at 11:36 PM Abby Spurdle > wrote: > > > > > > > First time posting in the R mailing lists so hopefully this works > well. > > > > I noticed when I type `R CMD` I get this unhelpful message: > > > > /usr/lib/R/bin/Rcmd: 60: shift: can't shift that many > > > > > > I wasn't able to reproduce this. > > > Maybe it's a Linux thing. > > > But then, I suspect you've omitted some of your input. > > > > > > > I also think it would be nice if `R CMD help` showed the usable > commands. > > > > > > What do you mean... > > > All of the following give you the "usable commands": > > > > > > > R CMD > > > > R CMD -h > > > > R CMD --help > > > > > > [[alternative HTML version deleted]] > > > > > > __ > > > 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
Re: [Rd] Making R CMD nicer
Yes I'm using R 3.4.4 on Ubuntu 18.04. I doubt the Windows version would make use of a bash script. I'm all for a more consistent interface. It puzzles me that a shell script is used at all since that does not seem portable, especially for Windows users. To my surprise I discovered the R that's called from shell, usr/bin/R, is actually just a shell script. The binary that's called seems to be /usr/lib/R/bin/exec/R which is a tiny executable that then probably calls something else. In comparison the python called from shell, /usr/bin/python3.6, really is a binary. I'm sure there's a good reason that R uses a shell wrapper script but it's not like a C program can't parse arguments or set env vars. On Sun, Jun 30, 2019 at 7:30 PM Gábor Csárdi wrote: > For the record, this is Linux R-devel: > > root@4bef68c16864:~# R CMD > /opt/R-devel/lib/R/bin/Rcmd: 60: shift: can't shift that many > root@4bef68c16864:~# R CMD -h > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: -h: not found > root@4bef68c16864:~# R CMD --help > /opt/R-devel/lib/R/bin/Rcmd: 62: exec: --help: not found > > This is R-release on macOS: > > ❯ R CMD > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: > /Library/Frameworks/R.framework/Resources/bin/: is a directory > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: > /Library/Frameworks/R.framework/Resources/bin/: cannot execute: > Undefined error: 0 > ❯ R CMD -h > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: -h: > invalid option > exec: usage: exec [-cl] [-a name] file [redirection ...] > ❯ R CMD --help > /Library/Frameworks/R.framework/Resources/bin/Rcmd: line 62: exec: --: > invalid option > exec: usage: exec [-cl] [-a name] file [redirection ...] > > On Windows you indeed get a useful list of commands and more helpful tips. > > Gabor > > > On Sun, Jun 30, 2019 at 11:36 PM Abby Spurdle wrote: > > > > > First time posting in the R mailing lists so hopefully this works well. > > > I noticed when I type `R CMD` I get this unhelpful message: > > > /usr/lib/R/bin/Rcmd: 60: shift: can't shift that many > > > > I wasn't able to reproduce this. > > Maybe it's a Linux thing. > > But then, I suspect you've omitted some of your input. > > > > > I also think it would be nice if `R CMD help` showed the usable > commands. > > > > What do you mean... > > All of the following give you the "usable commands": > > > > > R CMD > > > R CMD -h > > > R CMD --help > > > > [[alternative HTML version deleted]] > > > > __ > > 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] Problem using F77_CALL(dgemm) in a package
Dear R-devel,
I've written a numerical solver for SOCPs (second order cone programs)
in R, and now I want to move most of the solver code into C for speed.
I've written combined R/C packages before, but in this case I need to
do matrix operations in my C code. As I have never done that before,
I'm trying to write some simple examples to make sure I understand the
basics. I am stuck on the first one. I'm trying to write a function
to multiply two matrices using the blas routine dgemm. The name of my
example package is CMATRIX. My code is as follows.
I have a file matrix.c in my src directory:
#include
#include
#include
#include
//Computes C = A*B
void R_matrix_multiply(double * A, double * B, int * m, int *n, int *
p, double * C){
double one = 1.0;
double zero = 0.0;
//Just printing the input arguments
Rprintf("m = %d, n = %d, p = %d\n",*m,*n,*p);
int i;
for(i=0;i<(*m**n);i++){
Rprintf("%f ",A[i]);
}
Rprintf("\n");
for(i=0;i<(*n**p);i++){
Rprintf("%f ",B[i]);
}
Rprintf("\n");
for(i=0;i<(*m**p);i++){
Rprintf("%f ",C[i]);
}
Rprintf("\n");
//Here is the actual multiplication
F77_CALL(dgemm)("N","N",m,n,p,&one,A,m,B,n,&zero,C,m);
}
And the file C_matrix_multiply.R in my R directory:
C_matrix_multiply = function(A,B){
C <- matrix(0,nrow(A),ncol(B))
cout <-
.C("R_matrix_multiply",as.double(A),as.double(B),nrow(A),ncol(A),ncol(B),as.double(C))
return(matrix(cout$C,nrowA,ncol(B)))
}
My namespace file is:
export("C_matrix_multiply")
useDynLib(CMATRIX.so,R_matrix_multiply)
I'm not sure if it's necessary, but I've also included a Makevars.in
file in my src directory:
PKG_CPPFLAGS=@PKG_CPPFLAGS@
PKG_CFLAGS=@PKG_CFLAGS@
PKG_LIBS=@PKG_LIBS@ ${LAPACK_LIBS} ${BLAS_LIBS} ${FLIBS}
which I simply copied from the diversitree package, which seems to use
a lot of fortran. I have the same problem (which I am getting to)
with or without this Makevars.in file.
I install my package using:
R CMD INSTALL CMATRIX
Then I start up R and attempt to run the following code:
#Make some random matrices
A = matrix(rnorm(8),4,2)
B = matrix(rnorm(6),2,3)
#Load my package
library(CMATRIX)
#Print the matrices
A
B
#Try to multiply them
product = C_matrix_multiply(A,B)
What I want, and what according to my understanding should happen, is
for product to contain the same matrix as would result from A %*% B.
Instead, I get the following:
> A = matrix(rnorm(8),4,2)
> B = matrix(rnorm(6),2,3)
> library(CMATRIX)
> A
[,1] [,2]
[1,] -0.4981664 -0.7243532
[2,] 0.1428766 -1.5501623
[3,] -2.0624701 1.5104507
[4,] -0.5871962 0.3049442
> B
[,1][,2][,3]
[1,] 0.02477964 0.5827084 1.8434375
[2,] -0.20200104 1.7294264 0.9071397
> C_matrix_multiply(A,B)
m = 4, n = 2, p = 3
-0.498166 0.142877 -2.062470 -0.587196 -0.724353 -1.550162 1.510451 0.304944
0.024780 -0.202001 0.582708 1.729426 1.843437 0.907140
0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00
Parameter 10 to routine DGEMM was incorrect
Mac OS BLAS parameter error in DGEMM , parameter #0, (unavailable), is 0
and R immediately dies. I know the arguments are being passed into
the C code and everything up to my F77_CALL is functioning based on
the printed output. The problem is definitely something to do with my
F77_CALL(dgemm) line. My understanding is that parameter 10 should be
the leading dimension of the matrix B, which in this case should be
equal to 2, the number of rows in that matrix, which is what I am
doing. I have also considered that parameter numbering starts at 0,
in which case the incorrect parameter is &zero, but again that seems
correct to me. All of my reading and research suggests I am doing
everything correctly, so I am somewhat stumped. Perhaps I am missing
something simple or obvious, as I have never done this before and am
proceeding with only google and the R docs as my guide. I am
wondering if anybody can see what I'm doing wrong here, or perhaps
something I could do to try to fix it. Any assistance would be
greatly appreciated.
Best Regards,
Jason Rudy
Graduate Student
Bioinformatics and Medical Informatics Program
San Diego State University
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using F77_CALL(dgemm) in a package
It was indeed a simple problem! I took a look at that array.c as you
suggested and that cleared it right up. So, the correct C code is:
#include
#include
#include
#include
void R_matrix_multiply(double * A, double * B, int * m, int *n, int *
p, double * C){
double one = 1.0;
double zero = 0.0;
//Just printing the input arguments
Rprintf("m = %d, n = %d, p = %d\n",*m,*n,*p);
int i;
for(i=0;i<(*m**n);i++){
Rprintf("%f ",A[i]);
}
Rprintf("\n");
for(i=0;i<(*n**p);i++){
Rprintf("%f ",B[i]);
}
Rprintf("\n");
for(i=0;i<(*m**p);i++){
Rprintf("%f ",C[i]);
}
Rprintf("\n");
//Here is the actual multiplication
F77_CALL(dgemm)("N","N",m,p,n,&one,A,m,B,n,&zero,C,m);
}
The only difference being that I had the 4th and 5th arguments (n and
p) mixed up. There was also a problem in my R code after the
multiplication took place. For the record, the correct R code is:
C_matrix_multiply = function(A,B){
C <- matrix(0,nrow(A),ncol(B))
cout <-
.C("R_matrix_multiply",as.double(A),as.double(B),nrow(A),ncol(A),ncol(B),as.double(C))
return(matrix(cout[[6]],nrow(A),ncol(B)))
}
Thanks for the help. Now that I have a functioning example I am well
on my way to completing this project.
-Jason
On Sun, Feb 20, 2011 at 7:42 AM, Prof Brian Ripley
wrote:
> Look a close look at matprod in src/main/array in the R sources.
> Hint: it is the other dimensions you have wrong.
>
> And as BLAS is Fortran, counts do start at 1.
>
> On Sat, 19 Feb 2011, Jason Rudy wrote:
>
>> Dear R-devel,
>>
>> I've written a numerical solver for SOCPs (second order cone programs)
>> in R, and now I want to move most of the solver code into C for speed.
>> I've written combined R/C packages before, but in this case I need to
>> do matrix operations in my C code. As I have never done that before,
>> I'm trying to write some simple examples to make sure I understand the
>> basics. I am stuck on the first one. I'm trying to write a function
>> to multiply two matrices using the blas routine dgemm. The name of my
>> example package is CMATRIX. My code is as follows.
>>
>> I have a file matrix.c in my src directory:
>>
>> #include
>> #include
>> #include
>> #include
>>
>> //Computes C = A*B
>> void R_matrix_multiply(double * A, double * B, int * m, int *n, int *
>> p, double * C){
>> double one = 1.0;
>> double zero = 0.0;
>>
>> //Just printing the input arguments
>> Rprintf("m = %d, n = %d, p = %d\n",*m,*n,*p);
>> int i;
>> for(i=0;i<(*m**n);i++){
>> Rprintf("%f ",A[i]);
>> }
>> Rprintf("\n");
>> for(i=0;i<(*n**p);i++){
>> Rprintf("%f ",B[i]);
>> }
>> Rprintf("\n");
>> for(i=0;i<(*m**p);i++){
>> Rprintf("%f ",C[i]);
>> }
>> Rprintf("\n");
>>
>>
>> //Here is the actual multiplication
>> F77_CALL(dgemm)("N","N",m,n,p,&one,A,m,B,n,&zero,C,m);
>> }
>>
>> And the file C_matrix_multiply.R in my R directory:
>>
>> C_matrix_multiply = function(A,B){
>> C <- matrix(0,nrow(A),ncol(B))
>> cout <-
>> .C("R_matrix_multiply",as.double(A),as.double(B),nrow(A),ncol(A),ncol(B),as.double(C))
>> return(matrix(cout$C,nrowA,ncol(B)))
>>
>> }
>>
>> My namespace file is:
>>
>> export("C_matrix_multiply")
>> useDynLib(CMATRIX.so,R_matrix_multiply)
>>
>> I'm not sure if it's necessary, but I've also included a Makevars.in
>> file in my src directory:
>>
>> PKG_CPPFLAGS=@PKG_CPPFLAGS@
>> PKG_CFLAGS=@PKG_CFLAGS@
>> PKG_LIBS=@PKG_LIBS@ ${LAPACK_LIBS} ${BLAS_LIBS} ${FLIBS}
>>
>> which I simply copied from the diversitree package, which seems to use
>> a lot of fortran. I have the same problem (which I am getting to)
>> with or without this Makevars.in file.
>>
>> I install my package using:
>>
>> R CMD INSTALL CMATRIX
>>
>> Then I start up R and attempt to run the following code:
>>
>> #Make some random matrices
>> A = matrix(rnorm(8),4,2)
>> B = matrix(rnorm(6),2,3)
>>
>> #Load my package
>>
Re: [Rd] Problem using F77_CALL(dgemm) in a package
I've never used C++ before, so for this project I think I will stick with just using the BLAS and LAPACK routines directly. Another issue is that I will need to do some sparse matrix computations, for which I am planning to use CSPARSE, at least to begin with. I am interested by RcppArmadillo, and would consider it for future projects. If you don't mind, what in your opinion are the major pros and cons of an RcppArmadillo solution compared to simply using the BLAS or LAPACK routines through the .C interface? -Jason On Sun, Feb 20, 2011 at 8:11 AM, Dirk Eddelbuettel wrote: > > On 20 February 2011 at 09:50, Dirk Eddelbuettel wrote: > | There is of course merit in working through the barebones API but in case > you > | would consider a higher-level alternative, consider these few lines based on > | RcppArmadillo (which end up calling dgemm() for you via R's linkage to the > BLAS) > > PS I always forget that we have direct support in Rcpp::as<> for Armadillo > matrices. The examples reduces to three lines in C++, and you never need to > worry about row or column dimension, or memory allocation or deallocation: > > R> suppressMessages(library(inline)) > R> txt <- ' > + arma::mat Am = Rcpp::as< arma::mat >(A); > + arma::mat Bm = Rcpp::as< arma::mat >(B); > + return Rcpp::wrap( Am * Bm ); > + ' > R> mmult <- cxxfunction(signature(A="numeric", B="numeric"), > + body=txt, > + plugin="RcppArmadillo") > R> A <- matrix(1:9, 3, 3) > R> B <- matrix(9:1, 3, 3) > R> C <- mmult(A, B) > R> print(C) > [,1] [,2] [,3] > [1,] 90 54 18 > [2,] 114 69 24 > [3,] 138 84 30 > R> > > Matrices A and B from directly initialise Armadillo matrices, and the result > can be returned directly. > > Hth, Dirk > > -- > 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] Problem using F77_CALL(dgemm) in a package
I just tried that myself and the .Call version is substantially
faster. It seems like there is a lot more going on in the .Call C
code than the .C. Why is .Call faster? Does it have to do with the
way arguments are passed into the C function? I tried with DUP=FALSE
and NAOK=TRUE, but .Call was still the winner.
On Sun, Feb 20, 2011 at 4:27 PM, Simon Urbanek
wrote:
> Jason,
>
> FWIW the direct interface (.Call) is more efficient and makes passing things
> from R simpler:
>
> C_matrix_multiply = function(A,B) .Call("R_matrix_multiply", A, B)
>
> The drawback is a bit more legwork on the C side, but it also gives you more
> flexibility:
>
> SEXP R_matrix_multiply(SEXP A, SEXP B) {
> double one = 1.0;
> double zero = 0.0;
> int *dimA = INTEGER(getAttrib(A, R_DimSymbol));
> int *dimB = INTEGER(getAttrib(B, R_DimSymbol));
> SEXP sDimC = PROTECT(allocVector(INTSXP, 2));
> int *dimC = INTEGER(sDimC);
> SEXP C = PROTECT(allocVector(REALSXP, dimA[0] * dimB[1]));
> if (dimA[1] != dimB[0]) error("incompatible matrices!");
> dimC[0] = dimA[0];
> dimC[1] = dimB[1];
> setAttrib(C, R_DimSymbol, sDimC);
> A = PROTECT(coerceVector(A, REALSXP));
> B = PROTECT(coerceVector(B, REALSXP));
>
> F77_CALL(dgemm)("N","N",dimA,dimB+1,dimA+1,&one,REAL(A),dimA,REAL(B),dimA+1,&zero,REAL(C),dimA);
> UNPROTECT(4);
> return C;
> }
>
> For comparison:
>> A=matrix(rnorm(1e5),500)
>> B=matrix(rnorm(1e5),,500)
>
> .Call:
>
>> system.time(for (i in 1:10) C_matrix_multiply(A,B))
> user system elapsed
> 0.656 0.008 0.686
>
> .C:
>
>> system.time(for (i in 1:10) CC_matrix_multiply(A,B))
> user system elapsed
> 0.886 0.044 0.943
>
>
> in fact .Call is even a tiny bit faster than %*%:
>
>> system.time(for (i in 1:10) A %*% B)
> user system elapsed
> 0.658 0.004 0.665
>
> (it's not just a measurement error - it's consistent for more replications
> etc. - but it's really negligible - possibly just due to dispatch of %*%)
>
> Cheers,
> Simon
>
>
> On Feb 20, 2011, at 5:23 PM, Jason Rudy wrote:
>
>> It was indeed a simple problem! I took a look at that array.c as you
>> suggested and that cleared it right up. So, the correct C code is:
>>
>> #include
>> #include
>> #include
>> #include
>>
>> void R_matrix_multiply(double * A, double * B, int * m, int *n, int *
>> p, double * C){
>>
>> double one = 1.0;
>> double zero = 0.0;
>>
>> //Just printing the input arguments
>> Rprintf("m = %d, n = %d, p = %d\n",*m,*n,*p);
>> int i;
>> for(i=0;i<(*m**n);i++){
>> Rprintf("%f ",A[i]);
>> }
>> Rprintf("\n");
>> for(i=0;i<(*n**p);i++){
>> Rprintf("%f ",B[i]);
>> }
>> Rprintf("\n");
>> for(i=0;i<(*m**p);i++){
>> Rprintf("%f ",C[i]);
>> }
>> Rprintf("\n");
>>
>> //Here is the actual multiplication
>> F77_CALL(dgemm)("N","N",m,p,n,&one,A,m,B,n,&zero,C,m);
>> }
>>
>> The only difference being that I had the 4th and 5th arguments (n and
>> p) mixed up. There was also a problem in my R code after the
>> multiplication took place. For the record, the correct R code is:
>>
>> C_matrix_multiply = function(A,B){
>> C <- matrix(0,nrow(A),ncol(B))
>> cout <-
>> .C("R_matrix_multiply",as.double(A),as.double(B),nrow(A),ncol(A),ncol(B),as.double(C))
>> return(matrix(cout[[6]],nrow(A),ncol(B)))
>> }
>>
>> Thanks for the help. Now that I have a functioning example I am well
>> on my way to completing this project.
>>
>> -Jason
>>
>> On Sun, Feb 20, 2011 at 7:42 AM, Prof Brian Ripley
>> wrote:
>>> Look a close look at matprod in src/main/array in the R sources.
>>> Hint: it is the other dimensions you have wrong.
>>>
>>> And as BLAS is Fortran, counts do start at 1.
>>>
>>> On Sat, 19 Feb 2011, Jason Rudy wrote:
>>>
>>>> Dear R-devel,
>>>>
>>>> I've written a numerical solver for SOCPs (second order cone programs)
>>>> in R, and now I want to move most of the solver code into C for speed.
>>>> I've written combined R/C packages before, but in this case I
Re: [Rd] Problem using F77_CALL(dgemm) in a package
You're right about the code preceding .C. I stripped down the .C and
.Call codes to be as similar as possible, and the timings were much
closer.
R code:
Call_matrix_multiply = function(A,B){
C <- matrix(0,nrow(A),ncol(B))
.Call("R_CALL_matrix_multiply", A, B, C)
return(C)
}
C_matrix_multiply = function(A,B){
C <- matrix(0,nrow(A),ncol(B))
.C("R_matrix_multiply",A,B,nrow(A),ncol(A),ncol(B),C,DUP=FALSE,NAOK=TRUE)
return(C)
}
C code:
void R_CALL_matrix_multiply(SEXP A, SEXP B, SEXP C) {
double one = 1.0;
double zero = 0.0;
int *dimA = INTEGER(getAttrib(A, R_DimSymbol));
int *dimB = INTEGER(getAttrib(B, R_DimSymbol));
F77_CALL(dgemm)("N","N",dimA,dimB+1,dimA+1,&one,REAL(A),dimA,REAL(B),dimA+1,&zero,REAL(C),dimA);
}
void R_matrix_multiply(double * A, double * B, int * m, int *n, int *
p, double * C){
double one = 1.0;
double zero = 0.0;
//Here is the actual multiplication
F77_CALL(dgemm)("N","N",m,p,n,&one,A,m,B,n,&zero,C,m);
}
Timings:
> m = 2000
> n = 2000
> p = 2000
> A = matrix(rnorm(m*n),m,n)
> B = matrix(rnorm(n*p),n,p)
> library(CMATRIX)
> system.time(C_matrix_multiply(A,B))
user system elapsed
2.782 0.035 1.611
> system.time(Call_matrix_multiply(A,B))
user system elapsed
2.789 0.032 1.629
>
> m = 2000
> n = 2000
> p = 2000
> A = matrix(rnorm(m*n),m,n)
> B = matrix(rnorm(n*p),n,p)
> library(CMATRIX)
> system.time(C_matrix_multiply(A,B))
user system elapsed
2.793 0.029 1.609
> system.time(Call_matrix_multiply(A,B))
user system elapsed
2.787 0.029 1.586
Even so, it seems the .Call interface has a lot of advantages. I
think I will use it for this project and see how I like it.
Jason
On Tue, Feb 22, 2011 at 7:27 AM, Simon Urbanek
wrote:
> On Feb 22, 2011, at 1:55 AM, Jason Rudy wrote:
>
>> I just tried that myself and the .Call version is substantially
>> faster. It seems like there is a lot more going on in the .Call C
>> code than the .C. Why is .Call faster? Does it have to do with the
>> way arguments are passed into the C function? I tried with DUP=FALSE
>> and NAOK=TRUE, but .Call was still the winner.
>>
>
> .Call is the "native" interface so it passes all objects directly as
> references - essentially the same way that R uses internally (.C with
> DUP=FALSE and NAOK=TRUE comes close to that, though; the fastest is .External
> in this respect). Also you're allocating objects as you need them so there
> will be less copying afterwards. However, I suspect that major part of the
> difference is also in the code preceding the C code involved in this -- for
> example as.double() will implicitly create a copy since it needs to strip
> attributes whereas coerceVector is a no-op if the type matches.
>
> .C is there for historical compatibility - it is essentially equivalent to
> .Fortran which was the original (and only) interface way back when. .Call is
> in comparison a more recent addition, that's why you still find a lot of .C
> code. Personally I don't use .C at all because compared to .Call it is so
> cumbersome and error-prone (you can't even tell the length of the passed
> vectors in C!), but others have different preferences.
>
> Cheers,
> Simon
>
>
>> On Sun, Feb 20, 2011 at 4:27 PM, Simon Urbanek
>> wrote:
>>> Jason,
>>>
>>> FWIW the direct interface (.Call) is more efficient and makes passing
>>> things from R simpler:
>>>
>>> C_matrix_multiply = function(A,B) .Call("R_matrix_multiply", A, B)
>>>
>>> The drawback is a bit more legwork on the C side, but it also gives you
>>> more flexibility:
>>>
>>> SEXP R_matrix_multiply(SEXP A, SEXP B) {
>>> double one = 1.0;
>>> double zero = 0.0;
>>> int *dimA = INTEGER(getAttrib(A, R_DimSymbol));
>>> int *dimB = INTEGER(getAttrib(B, R_DimSymbol));
>>> SEXP sDimC = PROTECT(allocVector(INTSXP, 2));
>>> int *dimC = INTEGER(sDimC);
>>> SEXP C = PROTECT(allocVector(REALSXP, dimA[0] * dimB[1]));
>>> if (dimA[1] != dimB[0]) error("incompatible matrices!");
>>> dimC[0] = dimA[0];
>>> dimC[1] = dimB[1];
>>> setAttrib(C, R_DimSymbol, sDimC);
>>> A = PROTECT(coerceVector(A, REALSXP));
>>> B = PROTECT(coerceVector(B, REALSXP));
>>>
>>> F77_CALL(dgemm)("N","N",dimA,dimB
Re: [Rd] Problem using F77_CALL(dgemm) in a package
Thanks for the tip. That API could make my work considerably easier. Jason On Tue, Feb 22, 2011 at 7:37 AM, Douglas Bates wrote: > On Sun, Feb 20, 2011 at 4:39 PM, Jason Rudy wrote: >> I've never used C++ before, so for this project I think I will stick >> with just using the BLAS and LAPACK routines directly. Another issue >> is that I will need to do some sparse matrix computations, for which I >> am planning to use CSPARSE, at least to begin with. I am interested >> by RcppArmadillo, and would consider it for future projects. If you >> don't mind, what in your opinion are the major pros and cons of an >> RcppArmadillo solution compared to simply using the BLAS or LAPACK >> routines through the .C interface? > > You may want to consider the API exported by the Matrix package that > allows access to CHOLMOD functions in that package's library. The > entire CSPARSE library is also included in the Matrix package but most > of it is not exported because the CHOLMOD functions are generally more > effective. (Both CHOLMOD and CSPARSE are written by Tim Davis. > CSPARSE is good code but it was written more for instructional purpose > than as an "industrial strength" package.) > >> On Sun, Feb 20, 2011 at 8:11 AM, Dirk Eddelbuettel wrote: >>> >>> On 20 February 2011 at 09:50, Dirk Eddelbuettel wrote: >>> | There is of course merit in working through the barebones API but in case >>> you >>> | would consider a higher-level alternative, consider these few lines based >>> on >>> | RcppArmadillo (which end up calling dgemm() for you via R's linkage to >>> the BLAS) >>> >>> PS I always forget that we have direct support in Rcpp::as<> for Armadillo >>> matrices. The examples reduces to three lines in C++, and you never need to >>> worry about row or column dimension, or memory allocation or deallocation: >>> >>> R> suppressMessages(library(inline)) >>> R> txt <- ' >>> + arma::mat Am = Rcpp::as< arma::mat >(A); >>> + arma::mat Bm = Rcpp::as< arma::mat >(B); >>> + return Rcpp::wrap( Am * Bm ); >>> + ' >>> R> mmult <- cxxfunction(signature(A="numeric", B="numeric"), >>> + body=txt, >>> + plugin="RcppArmadillo") >>> R> A <- matrix(1:9, 3, 3) >>> R> B <- matrix(9:1, 3, 3) >>> R> C <- mmult(A, B) >>> R> print(C) >>> [,1] [,2] [,3] >>> [1,] 90 54 18 >>> [2,] 114 69 24 >>> [3,] 138 84 30 >>> R> >>> >>> Matrices A and B from directly initialise Armadillo matrices, and the result >>> can be returned directly. >>> >>> Hth, Dirk >>> >>> -- >>> Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com >>> >> >> __ >> 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] Displaying database records returned from postgresql to R through Java
Hi All,
I have a R script which returns a set of records from the postgresql to the
Java program and I want to print those records in Java.My script is like
this:
library(RPostgreSQL)
fnct1 <- function()
{
drv <- dbDriver("PostgreSQL")
r <- dbConnect(drv, host='local', port='1234',dbname='db',
user='user', password='pwd')
rs <- dbSendQuery(r,"select * from table1 where colm1 = 'val1'")
temp <- fetch(rs,n=-1)
return(temp)
}
My Java code is :
c.parseAndEval("try(source(\"scpt.R\"),silent=TRUE)");
res = c.parseAndEval("try(fnct1(), silent=TRUE)");
System.out.println("table names are:"+ res);
When I am printing res above it is displaying
`table names are:org.rosuda.REngine.REXPGenericVector@681a9515+[1]named`
as output. When I do something like `.asString()` or inside the
`System.out.println()` above then it throws error. How can I print or
access each record returned by R to Java?
*NOTE:* When I am running the same script file from R itself then R is
displaying some 10 records but when I am trying through Java then nothing
is getting displayed
Regards,
Jason
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Issues with installing RBGL package
Hi all,
I was installing a package *RBGL* of bioconductor. However, I had some
issues while installing it. I asked the devel group of bioconductor and
they told me to consult this group. Here is my conversation with the
bioconductor group related to the problem
*Me->*
I was trying to install the RBGL package using the following command
biocLite("RBGL")
However, I got the following error
*
installing *source* package RBGL ...
untarring boost include tree...
** libs
/usr/bin/clang++ -I/usr/local/Cellar/r/2.15.1/R.framework/Resources/include
-DNDEBUG -I/usr/local/Cellar/readline/6.2.4/include -isystem
/usr/local/include -I/usr/X11/include -Irbgl_trimmed_boost_1_49_0 -fPIC
-Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7 -c
bbc.cpp -o bbc.o
/usr/bin/clang++ -I/usr/local/Cellar/r/2.15.1/R.framework/Resources/include
-DNDEBUG -I/usr/local/Cellar/readline/6.2.4/include -isystem
/usr/local/include -I/usr/X11/include -Irbgl_trimmed_boost_1_49_0 -fPIC
-Os -w -pipe -march=native -Qunused-arguments -mmacosx-version-min=10.7 -c
cliques.cpp -o cliques.o
cliques.cpp:26:31: error: redefinition of 'p' as different kind of symbol
std::pair p;
^
rbgl_trimmed_boost_1_49_0/boost/mpl/assert.hpp:149:42: note: previous
definition is here
BOOST_MPL_AUX_ASSERT_CONSTANT( bool, p = !p_type::value );
^
rbgl_trimmed_boost_1_49_0/boost/mpl/assert.hpp:56:58: note: expanded from
macro 'BOOST_MPL_AUX_ASSERT_CONSTANT'
# define BOOST_MPL_AUX_ASSERT_CONSTANT(T, expr) enum { expr }
^
cliques.cpp:53:19: error: expression is not assignable
p = edge(*va1, *va2, g);
~ ^
cliques.cpp:54:25: error: member reference base type
'mpl_::assert_arg_pred_not>::' is not a
structure or union
if ( !p.second ) return FALSE;*
Any suggestions how to overcome this or what is causing this issue?
*Vincent Gray(of bioconductor group) -> *
please provide sessionInfo() and result of gcc -v
*Me->*
gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with:
/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
*sessionInfo() Results*
R version 2.15.1 (2012-06-22)
Platform: x86_64-apple-darwin11.4.0 (64-bit)
locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] BiocInstaller_1.8.3
loaded via a namespace (and not attached):
[1] tools_2.15.1
Thanks
Regards,
Jason
*Vincent Gray -> *
OK, I didn't read your log too well, so I missed that you are using
clang++. Theoretically it will work
http://blog.llvm.org/2010/05/clang-builds-boost.html
I am using the gcc supplied in Xcode 4.0.2, with
bash-3.2$ gcc -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~123/src/configure
--disable-checking --enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10-
--host=x86_64-apple-darwin10 --target=i686-apple-darwin10
--with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
this has no problem installing RBGL from source. your R is a little out of
date but I don't think that's an issue.
I have minimal experience with clang++ and you may have to take this to
R-help or R-devel if you are not going to use Xcode- based compilation, as
that's what we are basing our builds/tests on. I did try
bash-3.2$ clang++ -v
clang version 3.2 (tags/RELEASE_32/final)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
bash-3.2$ clang++ -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names
-undefined dynamic_lookup -single_module -multiply_defined suppress
-L/Users/stvjc/ExternalSoft/READLINE-62-DIST/lib -lreadline
-L//Users/stvjc/ExternalSoft/LIBICONV-64/lib -liconv
-L/Users/stvjc/ExternalSoft/jpeg-6b -ljpeg -o cliques.so cliques.o
-F/Users/stvjc/ExternalSoft/R-devel-dist/R.framework/.. -framework R
-Wl,-framework -Wl,CoreFoundation
and this aping of the
[Rd] Character Encoding: Why are valid Windows-1252 characters encoded as invalid ISO-8859-1 characters?
Something that looks like a bug to me - but as there may be a documented
reason I have missed, I wanted to ask about it here first. Please let me
know if this looks like something I should submit as a bug, if not, why
this behavior is intended.
Using RGui v2.15.3, 64bit, on a Windows 7 machine with US English locale
You can see the behavior I describe in the following
> Sys.getlocale("LC_CTYPE") # my default encoding is windows code page 1252
[1] "English_United States.1252"
> localeToCharset() # R thinks the best character set to use is ISO8859-1,
a subset of windows-1252
[1] "ISO8859-1"
> x<-"\x92" # I create a 'right quote' character, using a value valid in
windows-1252 but NOT VALID in ISO8859-1
> Encoding(x) # R has chosen to encode it as 'latin1' which seems to be a
synonym for ISO8859-1
[1] "latin1"
> x # Even tho character is invalid in latin1, it renders as if it were the
valid windows-1252 character
[1] ""
> enc2utf8(x) # Encoding as UTF-8 gives us, not a valid UTF-8 'right quote'
(/u2019), but the undefined unicode character 'PRIVATE USE TWO'
[1] "\u0092"
> enc2native(enc2utf8(x)) # Moving the UTF-8 to back to the native encoding
correctly shows that it can't render the 'PRIVATE USE TWO' character in
windows-1252
[1] ""
-
I think the problem occurs when R decides that the valid 1252 character
should be represented by default in a 'Latin1' (ISO8859-1) encoded string
rather than the native 'windows-1252'
Note that if we force the encoding to stay native, everything works fine:
--
> Encoding(x)<-"unknown" # Force the encoding to the native 1252
> enc2utf8(x) # Encoding as UTF-8 now gives us the valid UTF-8 'right
quote' character
[1] ""
> enc2native(enc2utf8(x)) # and going back to the native encoding works
exactly as it should
[1] ""
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Why change data type when dropping to one-dimension?
Hello,
First, let me say I'm an avid fan of R--it's incredibly powerful and I
use it all the time. I appreciate all the hard work that the many
developers have undergone.
My question is: why does the paradigm of changing the type of a 1D
return value to an unlisted array exist? This introduces boundary
conditions where none need exist, thus making the coding harder and
confusing.
For example, consider:
> d = data.frame(a=rnorm(10), b=rnorm(10));
> typeof(d); # OK;
> typeof(d[,1]); # Unexpected;
> typeof(d[,1,drop=F]); # Oh, now I see.
This is indeed documented in the R Language specification, but why is it
there in the first place? It doesn't make sense to the average
programmer to change the return type based on dimension.
Here it is again in 'sapply':
> sapply
> function (X, FUN, ..., simplify = TRUE, USE.NAMES = TRUE)
> {
> [...snip...]
>if (common.len == 1)
>unlist(answer, recursive = FALSE)
>else if (common.len > 1)
>array(unlist(answer, recursive = FALSE),
> dim = c(common.len,
>length(X)), dimnames = if (!(is.null(n1 <-
> names(answer[[1]])) &
>is.null(n2 <- names(answer
>list(n1, n2))
> [...snip...]
> }
So, in 'sapply', if your return value is one-dimensional be careful,
because the return type will not the be same as if it were otherwise.
Is this legacy or a valid, rational design decision which I'm not yet a
sophisticated enough R coder to enjoy?
Thanks,
-- Jason
--
Jason Vertrees, PhD
Dartmouth College : j...@cs.dartmouth.edu
Boston University : jas...@bu.edu
PyMOLWiki : http://www.pymolwiki.org/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Why change data type when dropping to one-dimension?
Thomas Lumley wrote: > On Fri, 29 May 2009, Jason Vertrees wrote: > >> My question is: why does the paradigm of changing the type of a 1D >> return value to an unlisted array exist? This introduces boundary >> conditions where none need exist, thus making the coding harder and >> confusing. >> >> For example, consider: >> > d = data.frame(a=rnorm(10), b=rnorm(10)); >> > typeof(d);# OK; >> > typeof(d[,1]); # Unexpected; >> > typeof(d[,1,drop=F]);# Oh, now I see. > > It does make it harder for programmers, but it makes it easier for > non-programmers. In particular, it is convenient to be able to do > d[1,1] to extract a number from a matrix, rather than having to > explicitly coerce the result to stop it being a matrix. > > At least the last two times this was discussed, there ended up being a > reasonable level of agreement that if someone's life had to be made > harder the programmers were better able to cope and that dropping > dimensions was preferable. > > -thomas > > Thomas LumleyAssoc. Professor, Biostatistics > tlum...@u.washington.eduUniversity of Washington, Seattle Thomas, Thanks for the quick response. I agree that extracting a number from a matrix/frame should result in a number not a matrix/frame. But, why do that for a 1D array of numbers? In my example, > d[,1]; is an array, not a single number. How does that help the novice user? I guess I just don't like the idea that the default result is to act unexpectedly and that a flag or boundary-conditional code is needed to "do the right thing". Regardless that's how it is, so I just need to learn the pitfalls for where that occurs. Thanks again, -- Jason -- Jason Vertrees, PhD Dartmouth College : j...@cs.dartmouth.edu Boston University : jas...@bu.edu PyMOLWiki : http://www.pymolwiki.org/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] setdiff bizarre (was: odd behavior out of setdiff)
Jay, I really appreciate all your help help. I posted to Nabble an R file and input CSV files more accurately demonstrating what I am seeing and the output I desire to achieve when I difference two dataframes. http://n2.nabble.com/Support-SetDiff-Discussion-Items...-td2999739.html It may be that "setdiff" as intended in the base R functionality and "prob" was never intended to provide the type of result I desire. If that is the case then I will need to ask the "Ninjas" for help to produce the out come I seek. That is, when I different the data within RSetDiffEntry.csv and RSetDuplicatesRemoved.csv, I desire to get the result shown in RDesired.csv. Note that, it would not be enough to just work to remove duplicate "CostPerSquareFoot" values, since that variable is tied to "EntryDate" and "HouseNumber". Any further help and insights are much appreciated. Thanks again, Jason --- On Fri, 5/29/09, G. Jay Kerns wrote: > From: G. Jay Kerns > Subject: setdiff bizarre (was: odd behavior out of setdiff) > To: r-devel@r-project.org > Cc: dwinsem...@comcast.net, jasonkrup...@yahoo.com > Date: Friday, May 29, 2009, 11:35 PM > Dear R-devel, > > Please see the recent thread on R-help, "Odd Behavior Out > of > setdiff(...) - addition of duplicate entries is not > identified" posted > by Jason Rupert. I gave an answer, then read David > Winsemius' answer, > and then did some follow-up investigation. > > I would like to change my answer. > > My current version of setdiff() is acting in a way that I > do not > understand, and a way that I suspect has > changed. Consider the > following, derived from Jason's OP: > > The base package setdiff(), atomic vectors: > > x <- 1:100 > y <- c(x,x) > > setdiff(x, y) # integer(0) > setdiff(y, x) # integer(0) > > z <- 1:25 > > setdiff(x,z) # 26:100 > setdiff(z,x) # integer(0) > > > Everything is fine. > > Now look at base package setdiff(), data frames??? > > > A <- data.frame(x = 1:100) > B <- rbind(A, A) > > setdiff(A, B) > # df 1:100? > setdiff(B, A) > # df 1:100? > > C <- data.frame(x = 1:25) > > setdiff(A, C) > # df 1:100? > setdiff(C, A) > # df 1:25? > > > > > I have read ?setdiff 37 times now, and I cannot divine any > interpretation that matches the above output. From > the source, it > appears that > > match(x, y, 0L) == 0L > > is evaluating to TRUE, of length equal to the columns of x, > and then > > x[match(x, y, 0L) == 0L] > > is returning the entire data frame. > > Compare with the output from package "prob", which uses a > setdiff that > operates row-wise: > > > ### > library(prob) > A <- data.frame(x = 1:100) > B <- rbind(A, A) > > setdiff(A, B) > # integer(0) > setdiff(B, A) > # integer(0) > > C <- data.frame(x = 1:25) > > setdiff(A, C) > # 26:100 > setdiff(C, A) > # integer(0) > > > > IMHO, the entire notion of "set" and "element" is > problematic in the > df case, so I am not advocating the adoption of the > prob:::setdiff > approach; rather, setdiff is behaving in a way that I > cannot believe > with my own eyes, and I would like to alert those who can > speak as to > why this may be happening. > > Thanks to Jason for bringing this up, and to David for > catching the discrepancy. > > Session info is below. I use the binaries prepared by > the Debian > group so I do not have the latest > patched-revision-4440986745343b. > This must have been related to something which has been > fixed since > April 17, and in that case, please disregard my message. > > Yours truly, > Jay > > > > > > > > sessionInfo() > R version 2.9.0 (2009-04-17) > x86_64-pc-linux-gnu > > locale: > LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices > utils datasets > methods base > > other attached packages: > [1] prob_0.9-1 > > > > > > > > > > > > > > > > > > -- > > *** > G. Jay Kerns, Ph.D. > Associate Professor > Department of Mathematics & Statistics > Youngstown State University > Youngstown, OH 44555-0002 USA > Office: 1035 Cushwa Hall > Phone: (330) 941-3310 Office (voice mail) > -3302 Department > -3170 FAX > E-mail: gke...@ysu.edu > http://www.cc.ysu.edu/~gjkerns/ > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inclusion of a new bandwidth selector for kernel density estimation in R stats
I understand that Prof. Ripley is largely responsible for the many kernel density estimation functions in R, especially the bw.SJ functions for the popular Sheather and Jones bandwidth selector. We have recently developed a new bandwidth selector that significantly improves SJ selector for difficult densities that deviates severely from normality but retains the superior performance of SJ selector for smoother ones. The paper (to appear in Journal of nonparametric statistics) is available at http://www.geocities.com/jg_liao/papers/kernel.pdf and the R function bw.liao is at http://www.geocities.com/jg_liao/software/bw_liao.txt The algorithm and R function appears to be very stable as it has processed more than 2 datasets without problem. We would love to work with Prof. Ripley or other R core member to make the new method part of R stats. Thanks. Jason Jason Liao, http://www.geocities.com/jg_liao [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AIX testers needed
Per the request to test the latest tarball referenced below, I have
built R on AIX 5.3. There is a memory issue, please see 3) below.
1) Build with --enable-BLAS-shlib option. Builds and
passes "make check".
2) GNU libiconv was installed; R configured *without*
the --without-
iconv option. Builds and passes "make check."
3) Memory issue:
a) Although the server possesses 8GB of RAM and
system("ulimit") returns "unlimited" as its value, R does not
"have enough memory."
b) This code works on R-2.4.0 on WinXP with 2GB of RAM, but
fails on the AIX build. Example code:
> xx <- matrix(rep(1e+10,1e7),nrow=1e4,ncol=1e3)
> tmp.df <- as.data.frame(cbind(xx,xx,xx))
Error: cannot allocate vector of size 228.9 Mb
> gc()
used (Mb) gc trigger (Mb) max used (Mb)
Ncells 233035 6.3 467875 12.5 35 9.4
Vcells 10104141 77.1 31854441 243.1 30104289 229.7
4) Used gcc-4.1.2; I have not tried the native compiler.
Questions:
1) Are there suggestions on how to diagnose and resolve the memory
issue? I'm still building my tool chain and I am in the midst of
installing gdb.
2) Regarding the build process itself, is there more documentation
or results that I should forward?
Thanks,
-jason
> version _
platform powerpc-ibm-aix5.3.0.0
arch powerpc
os aix5.3.0.0
system powerpc, aix5.3.0.0
status RC
major 2
minor 5.0
year 2007
month 04
day22
svn rev41276
language R
version.string R version 2.5.0 RC (2007-04-22 r41276)
- Original Message -
From: "Prof Brian Ripley" <[EMAIL PROTECTED]>
To:
Cc: "Sheth, Jagat K" <[EMAIL PROTECTED]>; "kamil
Marcinkowski" <[EMAIL PROTECTED]>; "Tiong Lim" <[EMAIL PROTECTED]>;
"Eric Harley" <[EMAIL PROTECTED]>; "Matthew Beason"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 28, 2007 11:27 PM
Subject: [Rd] AIX testers needed
> With much thanks to Ei-ji Nakama, R 2.5.0 alpha supports building on
> AIX
> (at least AIX 5.2 on one system).
>
> Would anyone able to test this please get the latest tarball from
>
> http://cran.r-project.org/src/base-prerelease/R-latest.tar.gz
>
> and try installing (after reading the AIX notes in R-admin.html
> section
> C.9).
>
> In particular it would be very helpful to know if
>
> 1) --enable-BLAS-shlib works (it is the default everywhere except
> AIX and
> Darwin)
>
> 2) if people succeed in installing GNU libiconv and building without
> needing --without-iconv.
>
> I am Cc:ing all the people I tracked down who reported attempted AIX
> installations in 2006 in the hope that they may still be interested.
>
> Please report success and any hints or problems in the R-devel list.
>
> --
> Brian D. Ripley, [EMAIL PROTECTED]
> 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
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AIX testers needed
Thank you for responding.
I should have added -a on my ulimit command. Here are its results;
which I believe are not the limiting factor.
%/ > ulimit -a
core file size(blocks, -c) 1048575
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max memory size (kbytes, -m) 32768
open files(-n) 2000
pipe size (512 bytes, -p) 64
stack size(kbytes, -s) hard
cpu time (seconds, -t) unlimited
max user processes(-u) 128
virtual memory(kbytes, -v) unlimited
Here are my gcc-v results. They are very similiar.
%/ > gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.3.0.0
Configured with: ../gcc-4.1.2/configure
--prefix=/opt/sas/msd/home/barnharj/usr/local
--program-suffix=-4.1.2
--enable-threads=aix
--enable-languages=c,c++,fortran
--disable-nls
--with-mpfr=/opt/sas/msd/home/barnharj/usr/local
--with-gmp=/opt/sas/msd/home/barnharj/usr/local
Thread model: aix
gcc version 4.1.2
My results for gcc -print-multi-lib are indentical to yours.
It should be noted that I did not attempt a 64 bit build. My system
is not configured properly for that just yet.
Via private correspondence someone also suggested the following
system("ulimit -d unlimited") during an R session. That failed as did
issuing the command before launching R.
I'll keep investigating.
My call to configure is listed below.
/configure --prefix=$HOME/usr/local --program-suffix=rc --with-readline=no
--with-x=no --enable-memory-profiling
- Original Message -
From: "Ei-ji Nakama" <[EMAIL PROTECTED]>
To: "Jason Barnhart" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, May 19, 2007 6:53 PM
Subject: Re: [Rd] AIX testers needed
> Hi.
>
> system("ulimit") of AIX gives back file block size.
> A limit of memory is `ulimit -m'.
>
> I made gcc-4.1.2 and made R-2.5.0+patched, but the problem did not
> happen.
>
> $ gcc-4.1 -v
> Using built-in specs.
> Target: powerpc-ibm-aix5.2.0.0
> Configured with: ../configure --with-as=/usr/bin/as
> --with-ld=/usr/bin/ld --disable-nls --prefix=/usr/local1/gcc-4.1.2
> --enable-threads --host=powerpc-ibm-aix5.2.0.0 --program-suffix=-4.1
> --with-gmp=/usr/local1 --with-mpfr=/usr/local1
> --enable-languages=c,c++,f95
> Thread model: aix
> gcc version 4.1.2
>
> $ gcc-4.1 -print-multi-lib
> .;
> pthread;@pthread
> ppc64;@maix64
> pthread/ppc64;@[EMAIL PROTECTED]
>
> $ export OBJECT_MODE=64
> $ ./configure CC="gcc-4.1 -maix64" \
> F77="gfortran-4.1 -maix64" \
> CXX="g++-4.1 -maix64" \
> --enable-BLAS-shlib --without-iconv
>
>
> 2007/5/19, Jason Barnhart <[EMAIL PROTECTED]>:
>> Per the request to test the latest tarball referenced below, I have
>> built R on AIX 5.3. There is a memory issue, please see 3) below.
>>
>> 1) Build with --enable-BLAS-shlib option. Builds and
>> passes "make check".
>>
>> 2) GNU libiconv was installed; R configured *without*
>> the --without-
>> iconv option. Builds and passes "make check."
>>
>> 3) Memory issue:
>> a) Although the server possesses 8GB of RAM and
>> system("ulimit") returns "unlimited" as its value, R does
>> not
>> "have enough memory."
>>
>> b) This code works on R-2.4.0 on WinXP with 2GB of RAM, but
>> fails on the AIX build. Example code:
>>
>> > xx <- matrix(rep(1e+10,1e7),nrow=1e4,ncol=1e3)
>> > tmp.df <- as.data.frame(cbind(xx,xx,xx))
>> Error: cannot allocate vector of size 228.9 Mb
>> > gc()
>>used (Mb) gc trigger (Mb) max used (Mb)
>> Ncells 233035 6.3 467875 12.5 35 9.4
>> Vcells 10104141 77.1 31854441 243.1 30104289 229.7
>>
>> 4) Used gcc-4.1.2; I have not tried the native compiler.
>>
>> Questions:
>>
>> 1) Are there suggestions on how to diagnose and resolve the
>> memory
>> issue? I'm still building my tool chain and I am in the midst
>> of
>> installing gdb.
>>
>> 2) Regarding the build process itself, is there more
>> documentation
>> or results that I should forward?
>>
>> Thanks,
>> -jason
>>
>>
>> > version _
>> platform powerpc-ibm-aix5.3.0.0
>> arch powerpc
>> os aix5.3.0.0
>> system powerpc, aix5.3.0.0
>> status RC
>&
Re: [Rd] AIX testers needed
Thanks for responding.
I don't think it's that simple. That's a soft limit, the hard limit
is "unlimited."
The results of gc() in the original post indicated that R could
utililize more than 32MB of RAM.
My sysadmin had already increased my memory limits prior to my
posting.
Just to confirm here are the results with ulimit -m set to unlimited
prior to calling R.
> xx <- matrix(rep(1e+10,1e7),nrow=1e4,ncol=1e3)
> object.size(xx)/1024^2
[1] 76.29405
> system("ulimit -m")
unlimited
> tmp.df <- as.data.frame(cbind(xx,xx,xx))
Error: cannot allocate vector of size 228.9 Mb
- Original Message -
From: "Hin-Tak Leung" <[EMAIL PROTECTED]>
To: "Jason Barnhart" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, May 21, 2007 11:02 AM
Subject: Re: [Rd] AIX testers needed
> Jason Barnhart wrote:
>> Thank you for responding.
>>
>> I should have added -a on my ulimit command. Here are its results;
>> which I believe are not the limiting factor.
>>
>> %/ > ulimit -a
>> core file size(blocks, -c) 1048575
>> data seg size (kbytes, -d) unlimited
>> file size (blocks, -f) unlimited
>> max memory size (kbytes, -m) 32768
>> open files(-n) 2000
>> pipe size (512 bytes, -p) 64
>> stack size(kbytes, -s) hard
>> cpu time (seconds, -t) unlimited
>> max user processes(-u) 128
>> virtual memory(kbytes, -v) unlimited
>
> you think max memory = 32768k (or 32MB) is not limiting?
> Please think again...
>
> HTL
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] AIX testers needed
Ei-ji,
Thank you very much for your reply; your suggestion resolved the
issue.
Follow up (for others):
1) In addition to setting the LDR_CNTRL environment variable
at run-time, R can be compiled by adding '-Wl,-
bmaxdata:0xn000' to LD_FLAGS (where 'n' is the number of
256MB increments of RAM requested) to engage large program
support (using GCC). This will support up to 2GB of RAM.
2) Setting LD_FLAGS set to '-Wl,-bmaxdata:0xD000/DSA' I
was able to compile R and use 3.0+ GB of RAM in a 32-bit
build. AIX documentation states this will support 3.5 GB of
RAM.
3) Under a 64-bit build, R could use all available RAM on the
server. One caveat here: requesting more RAM than the
system has available forces the OS to kill R without warning.
This could probably be prevented by using the -bmaxdata
option, but I have not tested this hypothesis.
4) AIX system documentation for 'Large Program Support' can
be found at
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp
for AIX 5.3 under 'Programming for AIX', then 'General
Programming Concepts: Writing and Debugging Programs'
- Original Message -
From: "Ei-ji Nakama" <[EMAIL PROTECTED]>
To: "Jason Barnhart" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, May 21, 2007 7:32 PM
Subject: Re: [Rd] AIX testers needed
> Hi.
>
> I was not careful to 32bit very much.
> You can expand memory for data to 2G by LDR_CNTRL.
> It is as follows.
>
> LDR_CNTRL="MAXDATA=0x1000" 1 256 MB
> LDR_CNTRL="MAXDATA=0x2000" 2 512 MB
> LDR_CNTRL="MAXDATA=0x3000" 3 768 MB
> LDR_CNTRL="MAXDATA=0x4000" 4 1024 MB
> LDR_CNTRL="MAXDATA=0x5000" 5 1280 MB
> LDR_CNTRL="MAXDATA=0x6000" 6 1536 MB
> LDR_CNTRL="MAXDATA=0x7000" 7 1792 MB
> LDR_CNTRL="MAXDATA=0x8000" 8 2048 MB
>
> try.
> $ export LDR_CNTRL="MAXDATA=0x8000"
> $ R -q
>> xx <- matrix(rep(1e+10,1e7),nrow=1e4,ncol=1e3)
>> tmp.df <- as.data.frame(cbind(xx,xx,xx))
>>
>
>
>
> 2007/5/22, Jason Barnhart <[EMAIL PROTECTED]>:
>> Thank you for responding.
>>
>> I should have added -a on my ulimit command. Here are its results;
>> which I believe are not the limiting factor.
>>
>> %/ > ulimit -a
>> core file size(blocks, -c) 1048575
>> data seg size (kbytes, -d) unlimited
>> file size (blocks, -f) unlimited
>> max memory size (kbytes, -m) 32768
>> open files(-n) 2000
>> pipe size (512 bytes, -p) 64
>> stack size(kbytes, -s) hard
>> cpu time (seconds, -t) unlimited
>> max user processes(-u) 128
>> virtual memory(kbytes, -v) unlimited
>>
>> Here are my gcc-v results. They are very similiar.
>>
>> %/ > gcc -v
>> Using built-in specs.
>> Target: powerpc-ibm-aix5.3.0.0
>> Configured with: ../gcc-4.1.2/configure
>> --prefix=/opt/sas/msd/home/barnharj/usr/local
>> --program-suffix=-4.1.2
>> --enable-threads=aix
>> --enable-languages=c,c++,fortran
>> --disable-nls
>> --with-mpfr=/opt/sas/msd/home/barnharj/usr/local
>> --with-gmp=/opt/sas/msd/home/barnharj/usr/local
>> Thread model: aix
>> gcc version 4.1.2
>>
>> My results for gcc -print-multi-lib are indentical to yours.
>>
>> It should be noted that I did not attempt a 64 bit build. My
>> system
>> is not configured properly for that just yet.
>>
>> Via private correspondence someone also suggested the following
>> system("ulimit -d unlimited") during an R session. That failed as
>> did
>> issuing the command before launching R.
>>
>> I'll keep investigating.
>>
>> My call to configure is listed below.
>>
>> /configure --prefix=$HOME/usr/local --program-suffix=rc --with-readline=no
>> --with-x=no --enable-memory-profiling
>>
>>
>> - Original Message -
>> From: "Ei-ji Nakama" <[EMAIL PROTECTED]>
>> To: "Jason Barnhart" <[EMAIL PROTECTED]>
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Saturday, May 19, 2007 6:53 PM
>> Subject: Re: [Rd] AIX testers needed
>>
>>
>> > Hi.
>> >
>> > system("ulimit") of AIX gives back file block size.
>> > A limit of memory is `ulimit -m'.
>> >
>> > I made gcc-4.1.2 and made R-2.5.0+patched, but the problem did
&
Re: [Rd] BLAS / LAPACK version information from within R-session?
And Brian Ripley writes: > I know of no way to ask a BLAS dynamic library what version it > is. Tinkering with the BLAS interface hasn't fared so well, but LAPACK 3.1 added an ILAVER subroutine that returns the major, minor, and patch level versions for LAPACK itself. >> An obvious application could be safety-checks for packages >> like Matrix and quantreg at load / attach - time. > > Why should that be needed? To warn of bugs in specific LAPACK versions, perhaps. I know I let a couple of embarassing typos merge into 3.1.0 with the eigenvalue drivers. The ones I know of so far only affect performance, but there may be another that leads to an unreported error. Looks like R makes DSYEVR available through eigen.R, so it's affected. Sorry. And I know prior LAPACK versions have some painful error cases. They seem to impact few people, so having the LAPACK version in related bug reports may help remove those causes. >> Perhaps this information may even be included into the output >> of R.Version() :-) ? > > I can think of more worthy candidates, e.g. the compilers used > to build R, and for Linux something more precise about the > distro used. Alas, yes, those could be very useful with the resurgence of funny arithmetics. Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How can I list unregistered routines from loaded DLLs?
Hi, I want to load DLLs that have been compiled in C or C++ (using dyn.load), and then get a list of all routines contained in that DLL. getRegisteredRoutines doesn't work, because the routines have not been registered. It's a catch-22 because I can't (so far as I can see) register the routines without knowing their names, and I can't (so far as I can see) get a list of their names unless they are registered. Is there a way around this, besides making guesses about the names and testing them with is.loaded()? Thanks in advance, Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 0 ^ NaN == Inf, why?
And John Chambers writes: > I tried a little harder, and apparently the guess is wrong. It seems > that pow(0, -0) is 1 in C. Would seem better to either have pow(0,0) > and pow(0,-0) both be NaN or else 1 and Inf, but ... There are slides from Jim Thomas summarizing the C99 choices for elementary functions at http://grouper.ieee.org/groups/754/meeting-materials/2001-07-18-c99.pdf or in an html version in the meeting notes at http://grouper.ieee.org/groups/754/meeting-minutes/01-07-18.html IIRC, pow(x, +/- 0) is taken to be 1 for all x because pow(x, 0) = 1 and pow(x, -0) = 1/pow(x, 0) = 1/1 = 1 for all finite, numerical, non-zero x. The NCEG folks spent a huge effort considering mathematical reasons and actual applications when they chose the special case values. Disagreements over special cases are natural, alas, but they did the best anyone really could. Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Listing of LAPACK error codes
And Orlando Döhring writes: > Is there a listing for the error codes from Lapack routine 'dsyevr'? The HTML-ized LAPACK functions are at http://www.netlib.org/lapack/explore-html/ although they may lag behind releases a little bit. The page for dsyevr.f is: http://www.netlib.org/lapack/explore-html/dsyevr.f.html And the LAPACK mailing list is at lap...@cs.utk.edu, although as with all such projects, responses may be a *long* time in coming. > Especially I am interested about the meaning and handling of error codes 1 > and 2. The high-level drivers like DSYEVR dispatch to different internal routines depending on what was requested. That makes documenting the error codes a little painful... For some of the routines involved, INFO.eq.1 or 2 implies 1 or 2 entries didn't converge, either when reducing a tridiagonal to diagonal, in bisection, or in inverse iteration. For another, but only if you're requesting the ilo-th through ihi-th eigenvalues, 2 would imply non-monotonic arithmetic, and I would be *very* surprised. So likely something somewhere didn't converge. Picking parameters that *always* converge for eigenvalues is an open problem. Have you tried this on different platforms, or with different BLAS? Can you release the data that causes the problem? Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Memory allocator on OS/X
A quick scan though the mailing list archives didn't reveal any reference to this article, so here goes: http://ridiculousfish.com/blog/archives/2006/05/16/36/ In response to a criticism of OS X, a diligent blogger examined a claim that it was an inherently slow operating system. The application in question was R, and the results were... "Linux uses ptmalloc, which is a thread-safe implemenation based on Doug Lea’s allocator (Sekhon’s test is single threaded, incidentally). R also uses the Lea allocator on Windows instead of the default Windows malloc. But on Mac OS X, it uses the default allocator." ... and ... "If you use the same allocator on Mac OS X that R uses on Windows, the performance differences all but disappear." Would it make sense for the build process that generates R binaries for OS X to use the Lea allocator? Jason Foster __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Memory allocator on OS/X
> Somehow you managed to miss it, we had a discussion about this > quite recently: > http://www.mail-archive.com/r-sig-mac%40stat.math.ethz.ch/ > msg00770.html My bad; I focused on the r-devel list and didn't check the SIG. Sorry about the noise. Jason __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] data frame subset patch, take 2
I think the efficiency gain is worthwhile. Thx. -jason - Original Message - From: "Martin Maechler" <[EMAIL PROTECTED]> To: "Marcus G. Daniels" <[EMAIL PROTECTED]> Cc: ; "Vladimir Dergachev" <[EMAIL PROTECTED]> Sent: Tuesday, December 12, 2006 10:08 AM Subject: Re: [Rd] data frame subset patch, take 2 [SNIP] > Note however that some of these changes are backward > incompatible. I do hope that the changes gaining efficiency > for such large data frames are worth some adaption of > current/old R source code.. > > Feedback on this topic is very welcome! > > Martin > [SNIP] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R <-> Haskell
I'd like to develop, if there is not one already, an interface between R
code and Haskell code, to allow R code to call Haskell (compiled) code, and
vice-versa. But in the interest of not reinventing the wheel, does anyone
on this list know of existing bindings for Haskell code?
There is support for loading plugins in Haskell, and for an eval() like set
of functions provided by the Haskell hs-plugin package that evaluates
arbitrary strings in the IO monad.
http://www.cse.unsw.edu.au/~dons/hs-plugins/paper/ describes this
functionality. For example:
#include
#include "RunHaskell.h"
int main(int argc, char *argv[]) {
int *p;
hs_init(&argc, &argv);
p = hs_eval_i("foldl1 (+) [0 .. 10]"); /* this is Haskell code */
printf("%d\n", *p); hs_exit();
}
That said, i don't think it will be that difficutl. But I imagine the
hardest part of this will be getting the memory management for garbage
collection right. I thought I would start by looking at how the rJava or
rJython packages handle memory. If anyone has pointers or advice on
integrating R's garbage collection with another language's garbage
collection, I'd welcome suggestions and warnings about pitfalls.
Thanks,
Jason
--
Jason E. Aten, Ph.D.
j.e.a...@gmail.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R <-> Haskell
Thank you Gabor. Yes, I've looked at the Ocaml-R bindings. They are in
fact where I got the notion that the integration of two garbage collection
systems can be tricky. Guillaume Yziquel, the author of the Ocaml-R
bindings wrote to me that:
"As for speed, currently, there's a very inefficient interaction between
OCaml's GC and R's GC. If you have n R values that are being held by
OCaml, you free each value in O(n), meaning quadratic time to free the
whole bunch. There is a solution to this, but I did not find the time to
implement it. And of course, the speed is only on the OCaml side, not on
the R side."
and hence I am especially conscious of the traps for the unwary when
integrating two GCs.
On Sat, Dec 11, 2010 at 9:19 PM, Gabor Grothendieck wrote:
> On Sat, Dec 11, 2010 at 9:04 PM, Jason E. Aten wrote:
> > I'd like to develop, if there is not one already, an interface between R
> > code and Haskell code, to allow R code to call Haskell (compiled) code,
> and
> > vice-versa. But in the interest of not reinventing the wheel, does
> anyone
> > on this list know of existing bindings for Haskell code?
> >
> > There is support for loading plugins in Haskell, and for an eval() like
> set
> > of functions provided by the Haskell hs-plugin package that evaluates
> > arbitrary strings in the IO monad.
> > http://www.cse.unsw.edu.au/~dons/hs-plugins/paper/<http://www.cse.unsw.edu.au/%7Edons/hs-plugins/paper/>describes
> > this
> > functionality. For example:
> >
> > #include
> > #include "RunHaskell.h"
> >
> > int main(int argc, char *argv[]) {
> > int *p;
> > hs_init(&argc, &argv);
> > p = hs_eval_i("foldl1 (+) [0 .. 10]"); /* this is Haskell code */
> > printf("%d\n", *p); hs_exit();
> > }
> >
> >
> >
> > That said, i don't think it will be that difficutl. But I imagine the
> > hardest part of this will be getting the memory management for garbage
> > collection right. I thought I would start by looking at how the rJava or
> > rJython packages handle memory. If anyone has pointers or advice on
> > integrating R's garbage collection with another language's garbage
> > collection, I'd welcome suggestions and warnings about pitfalls.
> >
>
> You might look at:
>
> http://home.gna.org/ocaml-r/
>
> --
> Statistics & Software Consulting
> GKX Group, GKX Associates Inc.
> tel: 1-877-GKX-GROUP
> email: ggrothendieck at gmail.com
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] switching to an previous R engine?
Hello, I have quite a few programs that I have written over the last 5 years that rely on the old R engine (2.6.2 and earlier) returning a null when an invalid index is used, as in: > df <- data.frame(x = 1) > df[,'y'] NULL Is there a way to tell R to return NULLs instead of raising errors within a function or package? I'm a fan of the raising errors instead of returning values that could be confused with a legitimate return value, but for now I'm stuck using 2.6.2 until I have time to check every line of code I've written in the last 5 years. Thanks! Jason Thorpe [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
