Re: [Rd] Wishlist - Give R a name that shows up in search engines...
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> > on Mon, 06 Mar 2006 19:21:50 -0500 writes: Duncan> On 3/6/2006 4:09 PM, Tim Brown wrote: >> Hi everyone, >> >> I know this is a long shot but I just wanted to throw it >> out there. I have lately been using R a lot and have >> found that it is basically impossible to find any code >> help or answers via google searching because the name "R" >> is simply not explicit enough. Duncan> That hasn't been my experience. Could you post some Duncan> examples of your searches? Duncan> For example, "find length of array in R" turns up Duncan> R-specific answers in 4th and 9th positions on the Duncan> first page of results. Using "find length of array, Duncan> R Project" turns up 6 out of 10 hits referencing R. in which google? The one in the US, in Europe, in China, or ... ? As we probably all know the censorship differs from place to place .. and it seems one has no way to circumvent Big-Brother Google's decisions anymore. Sorry, but I couldn't refrain; I had been very disappointed by these news. Martin Maechler Duncan> For >> every other popular program or programming language a >> simple search with the name of the program and your >> problem brings up something pretty close to the answer, >> its usually just a matter of phrasing it so the results >> you are looking come up in your search (e.g. "find length >> of array, Matlab"). Try a similar web search for R and >> you will learn nothing -- Why? because the letter "R" is >> on almost every web page on the planet. >> >> I'm not just whining here, I think this is a really >> serious problem. On the web, "findability" is perhaps >> the single most important feature of any product or >> program. The unique beauty of the Web anyone who solves >> any problem can post the answer almost anywhere want, a >> search engines will index it and serve it up to someone >> looking for a solution to that problem. Of course it >> doesn't quite work like that but its pretty close if you >> trying to find out how to program something in most >> languages and programs. You can't do this in R because >> its name is not unique enough, and that seriously hampers >> the ability of both new and expert users to accomplish >> things quickly. I realize that there is the R-project >> website and so on, but the decentralized nature of the >> web assures that not not everyone will post their answers >> there and people such as me who search google first >> rather than going straight to a single site will have a >> hard time finding answers. >> >> So seriously, has there ever been any discussion about >> renaming R so that people's hard work on making this >> kick-butt program can be shared and searched with the >> same facility that other programs enjoy. It could be >> something as simple as "R plus" ;) just anything that >> makes it unique enough that R program pages aren't >> indexed with 100 billion pages that happen to have a >> single R on them for some reason. >> >> Cheers, >> >> Tim >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel Duncan> __ Duncan> R-devel@r-project.org mailing list Duncan> 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] Running R on dual/quad Opteron machines
Ok thanks, I am wondering whether running multiple instances of R would be possible without problems in presence of compiled code (shared libraries). Intuitively, while there can be multiple instances of R, all of them would be using the same library, but I am just guessing, I might do a check on this. Ciao Simone > > And let me couch my earlier statements on snow/Rmpi by saying that we use > these tools on a relatively large beowulf cluster (~200 nodes), which is > somewhat different than a single box with 2-4 processors, so it is may not > be worth the trouble outside of a cluster environment. For example, we have > not moved to using Rmpi/snow on our dual-processor G5s because the speed > gain just isn't worth the extra installation trouble, etc. > > Sean > > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Running R on dual/quad Opteron machines
On Tue, 7 Mar 2006, Simone Giannerini wrote: > Ok thanks, I am wondering whether running multiple instances of R > would be possible without problems in presence of compiled code > (shared libraries). > Intuitively, while there can be multiple instances of R, all of them > would be using the same library, but I am just guessing, I might do a > check on this. That's what the `shared library' means. The common parts (e.g. code and static data) are shared, but the data areas are not. Different processes run in different address spaces, and modern OSes are careful only to give a user process write access to its own address space. Many of us have servers running multiple copies of R at almost all times. I typically run R tests with four copies running on a dual-CPU Opteron, that being about the minimum number needed to get 100% CPU usage since I/O is also being done. > > Ciao > > Simone > >> >> And let me couch my earlier statements on snow/Rmpi by saying that we use >> these tools on a relatively large beowulf cluster (~200 nodes), which is >> somewhat different than a single box with 2-4 processors, so it is may not >> be worth the trouble outside of a cluster environment. For example, we have >> not moved to using Rmpi/snow on our dual-processor G5s because the speed >> gain just isn't worth the extra installation trouble, etc. >> >> Sean -- 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
Re: [Rd] Wishlist - Give R a name that shows up in search engines...
Hi, I have given up on "R" with any topic on Google quite some time ago (because bits from fragmented postscript/pdf files show up, for example) - but using "r-devel" with topic normally gives me enough. YMMV. HTL Tim Brown wrote: > Hi everyone, > > I know this is a long shot but I just wanted to throw it out > there. I have lately been using R a lot and have found that it is > basically impossible to find any code help or answers via google > searching because the name "R" is simply not explicit enough. For > every other popular program or programming language a simple search > with the name of the program and your problem brings up something > pretty close to the answer, its usually just a matter of phrasing it > so the results you are looking come up in your search (e.g. "find > length of array, Matlab"). Try a similar web search for R and you > will learn nothing -- Why? because the letter "R" is on almost every > web page on the planet. > > I'm not just whining here, I think this is a really serious problem. > On the web, "findability" is perhaps the single most important > feature of any product or program. The unique beauty of the Web > anyone who solves any problem can post the answer almost anywhere > want, a search engines will index it and serve it up to someone > looking for a solution to that problem. Of course it doesn't quite > work like that but its pretty close if you trying to find out how to > program something in most languages and programs. You can't do this > in R because its name is not unique enough, and that seriously > hampers the ability of both new and expert users to accomplish things > quickly. I realize that there is the R-project website and so on, > but the decentralized nature of the web assures that not not everyone > will post their answers there and people such as me who search google > first rather than going straight to a single site will have a hard > time finding answers. > > So seriously, has there ever been any discussion about renaming R so > that people's hard work on making this kick-butt program can be > shared and searched with the same facility that other programs enjoy. > It could be something as simple as "R plus" ;) just anything that > makes it unique enough that R program pages aren't indexed with 100 > billion pages that happen to have a single R on them for some reason. > > Cheers, > > Tim > > __ > 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] double pointer matrix
Hello,
I'm having some difficulty to understand how I could
take the proper result from the following listing:
-- cut ---
#include
#include
#include
void retMat ( double **y, int *n, int *m, double *a,
double *b) {
int i, j;
y = malloc( (*n) * sizeof( double ) );
for (i=0; i<*n; i++) {
y[i] = malloc ( (*m) * sizeof( double
) );
}
GetRNGstate();
for (i=0; i<*n; i++) {
for (j=0; j<*m; j++) {
y[i][j] = (i+1)*(j+1)*rbeta(
*a, *b );
}
}
PutRNGstate();
}
---
I understand that I will have to make the matrix
initialized in the double for loop above to be somehow
visible as a vector, because of the way that the
matrix elements are passed in the argument when used
in the R space. Is there a way to accomplish this?
Thanks for any answers,
- b.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] double pointer matrix
Please don't do malloc inside C code like this - it won't interact too
well with the garbage collector in R, and your program probably will
either leak or crash or both... and when are you going to do your
free()?
What you want is do is to delete that malloc line and do the
allocation on the R side, something like this (the first line does
the equivalent of your malloc allocation):
y <- double(n)
y <- .C("retMat", as.double(y), as.double(n), as.double(m),
as.double(a), as.double(b))[1]
HTL
Bernd Kriegstein wrote:
> Hello,
>
> I'm having some difficulty to understand how I could
> take the proper result from the following listing:
>
> -- cut ---
> #include
> #include
> #include
>
> void retMat ( double **y, int *n, int *m, double *a,
> double *b) {
> int i, j;
> y = malloc( (*n) * sizeof( double ) );
> for (i=0; i<*n; i++) {
> y[i] = malloc ( (*m) * sizeof( double
> ) );
> }
>
> GetRNGstate();
>
> for (i=0; i<*n; i++) {
> for (j=0; j<*m; j++) {
> y[i][j] = (i+1)*(j+1)*rbeta(
> *a, *b );
> }
> }
>
> PutRNGstate();
> }
> ---
> I understand that I will have to make the matrix
> initialized in the double for loop above to be somehow
> visible as a vector, because of the way that the
> matrix elements are passed in the argument when used
> in the R space. Is there a way to accomplish this?
>
> Thanks for any answers,
>
> - b.
>
> __
> 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] Running R on dual/quad Opteron machines
Dear prof. Ripley, many thanks for the clarification, now I have good elements for managing the purchase. kind regards, Simone Giannerini On 3/7/06, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Tue, 7 Mar 2006, Simone Giannerini wrote: > > > Ok thanks, I am wondering whether running multiple instances of R > > would be possible without problems in presence of compiled code > > (shared libraries). > > Intuitively, while there can be multiple instances of R, all of them > > would be using the same library, but I am just guessing, I might do a > > check on this. > > That's what the `shared library' means. The common parts (e.g. code and > static data) are shared, but the data areas are not. > > Different processes run in different address spaces, and modern OSes are > careful only to give a user process write access to its own address space. > > Many of us have servers running multiple copies of R at almost all times. > I typically run R tests with four copies running on a dual-CPU Opteron, > that being about the minimum number needed to get 100% CPU usage since I/O > is also being done. > > > > > Ciao > > > > Simone > > > >> > >> And let me couch my earlier statements on snow/Rmpi by saying that we use > >> these tools on a relatively large beowulf cluster (~200 nodes), which is > >> somewhat different than a single box with 2-4 processors, so it is may not > >> be worth the trouble outside of a cluster environment. For example, we > >> have > >> not moved to using Rmpi/snow on our dual-processor G5s because the speed > >> gain just isn't worth the extra installation trouble, etc. > >> > >> Sean > > -- > 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 > -- __ Simone Giannerini Dipartimento di Scienze Statistiche "Paolo Fortunati" Universita' di Bologna Via delle belle arti 41 - 40126 Bologna, ITALY Tel: +39 051 2098248 Fax: +39 051 232153 E-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Expanding partial names
I'm writing wrappers for some functions that change some of the default
arguments. I'd rather not list all of the arguments for the low level
functions because there are about a dozen wrapper functions, and about
20 arguments to lowlevel. Instead I'm trying something like this:
lowlevel <- function(longname = 1) {
cat("longname = ", longname, "\n")
}
wrapper <- function(...) {
newargs <- list(longname = 2)
newargs[names(list(...))] <- list(...)
do.call("lowlevel", newargs)
}
This almost works:
> wrapper()
longname = 2
> wrapper(longname = 3)
longname = 3
But it fails if I try to use partial argument matching:
> wrapper(long=4)
Error in lowlevel(longname = 2, long = 4) :
unused argument(s) (long ...)
because long isn't matched to longname. Is there a reasonable way to do
this (e.g. using pmatch or charmatch) other than listing all the low
level arguments in the argument list to wrapper?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] possible bug: NULL equality in lists.
I was messing around with R and I found an example R behaving oddly: a <- alist(NULL, "bob", c(3,6,2,3)) a a == 'NULL' a == "NULL" a == 'cat' If I create a list with a NULL value >a <- alist(NULL, "bob", c(3,6,2,3)) >a [[1]] NULL [[2]] [1] "bob" [[3]] c(3, 6, 2, 3) and run some tests on 'a', the '== "NULL' test returns TRUE for the NULL entry in the list 'a'. >a == 'NULL' [1] TRUE FALSE FALSE >a == "NULL" [1] TRUE FALSE FALSE >a == 'cat' [1] FALSE FALSE FALSE This is consistent for every example of NULL's in a list that I can think of. Is this a bug or undocumented correct behavior? Here is my version output platform i486-pc-linux-gnu arch i486 os linux-gnu system i486, linux-gnu status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R Thanks Charles -- Charles Dupont Computer System Analyst School of Medicine Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
Try this:
wrapper <- function(...) {
args <- list(...)
if (length(args)) {
nf <- names(formals(lowlevel))
nams <- nf[pmatch(names(args), nf)]
args <- replace(list(longname = 2), nams, args)
}
do.call("lowlevel", args)
}
Here is a test:
> wrapper()
longname = 1
> wrapper(longname = 34)
longname = 34
> wrapper(long = 34)
longname = 34
On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> I'm writing wrappers for some functions that change some of the default
> arguments. I'd rather not list all of the arguments for the low level
> functions because there are about a dozen wrapper functions, and about
> 20 arguments to lowlevel. Instead I'm trying something like this:
>
> lowlevel <- function(longname = 1) {
> cat("longname = ", longname, "\n")
> }
>
> wrapper <- function(...) {
> newargs <- list(longname = 2)
> newargs[names(list(...))] <- list(...)
> do.call("lowlevel", newargs)
> }
>
> This almost works:
>
> > wrapper()
> longname = 2
> > wrapper(longname = 3)
> longname = 3
>
> But it fails if I try to use partial argument matching:
>
> > wrapper(long=4)
> Error in lowlevel(longname = 2, long = 4) :
> unused argument(s) (long ...)
>
> because long isn't matched to longname. Is there a reasonable way to do
> this (e.g. using pmatch or charmatch) other than listing all the low
> level arguments in the argument list to wrapper?
>
> Duncan Murdoch
>
> __
> 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] possible bug: NULL equality in lists.
Charles Dupont wrote: > I was messing around with R and I found an example R behaving oddly: > > a <- alist(NULL, "bob", c(3,6,2,3)) > a > a == 'NULL' > a == "NULL" > a == 'cat' > Always use is.null() to test on NULL, as in: sapply(a, is.null) Uwe Ligges > If I create a list with a NULL value > >a <- alist(NULL, "bob", c(3,6,2,3)) > >a > [[1]] > NULL > > [[2]] > [1] "bob" > > [[3]] > c(3, 6, 2, 3) > > and run some tests on 'a', the '== "NULL' test returns TRUE for the NULL > entry in the list 'a'. > >a == 'NULL' > [1] TRUE FALSE FALSE > >a == "NULL" > [1] TRUE FALSE FALSE > >a == 'cat' > [1] FALSE FALSE FALSE > > This is consistent for every example of NULL's in a list that I can > think of. > > Is this a bug or undocumented correct behavior? > > Here is my version output > > platform i486-pc-linux-gnu > arch i486 > os linux-gnu > system i486, linux-gnu > status > major2 > minor2.0 > year 2005 > month10 > day 06 > svn rev 35749 > language R > > > Thanks > > Charles __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
On 3/7/2006 9:42 AM, Gabor Grothendieck wrote:
> Try this:
>
>
> wrapper <- function(...) {
> args <- list(...)
> if (length(args)) {
> nf <- names(formals(lowlevel))
> nams <- nf[pmatch(names(args), nf)]
> args <- replace(list(longname = 2), nams, args)
> }
> do.call("lowlevel", args)
> }
>
> Here is a test:
>
>> wrapper()
> longname = 1
>> wrapper(longname = 34)
> longname = 34
>> wrapper(long = 34)
> longname = 34
Thanks, that's getting close, but it doesn't quite handle errors cleanly:
> wrapper(junk=3)
Error in lowlevel(longname = 2, "NA" = 3) :
unused argument(s) (NA ...)
It looks like I'll need something fairly elaborate.
Duncan Murdoch
> On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> I'm writing wrappers for some functions that change some of the default
>> arguments. I'd rather not list all of the arguments for the low level
>> functions because there are about a dozen wrapper functions, and about
>> 20 arguments to lowlevel. Instead I'm trying something like this:
>>
>> lowlevel <- function(longname = 1) {
>> cat("longname = ", longname, "\n")
>> }
>>
>> wrapper <- function(...) {
>> newargs <- list(longname = 2)
>> newargs[names(list(...))] <- list(...)
>> do.call("lowlevel", newargs)
>> }
>>
>> This almost works:
>>
>> > wrapper()
>> longname = 2
>> > wrapper(longname = 3)
>> longname = 3
>>
>> But it fails if I try to use partial argument matching:
>>
>> > wrapper(long=4)
>> Error in lowlevel(longname = 2, long = 4) :
>> unused argument(s) (long ...)
>>
>> because long isn't matched to longname. Is there a reasonable way to do
>> this (e.g. using pmatch or charmatch) other than listing all the low
>> level arguments in the argument list to wrapper?
>>
>> Duncan Murdoch
>>
>> __
>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
The original code was not intended to be fully finished.
It was just to give the idea so I left out the error checking.
Adding such a check is just a matter of adding an if
statement to check the pmatch for NA:
wrapper <- function(...) {
args <- list(...)
if (length(args)) {
nf <- names(formals(lowlevel))
idx <- pmatch(names(args), nf)
if (any(is.na(idx)))
stop(paste("Invalid names used:", names(args)[is.na(idx)]))
nams <- nf[idx]
args <- replace(list(longname = 2), nams, args)
}
do.call("lowlevel", args)
}
wrapper(long = 3)
wrapper(junk = 5)
On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> On 3/7/2006 9:42 AM, Gabor Grothendieck wrote:
> > Try this:
> >
> >
> > wrapper <- function(...) {
> > args <- list(...)
> > if (length(args)) {
> > nf <- names(formals(lowlevel))
> > nams <- nf[pmatch(names(args), nf)]
> > args <- replace(list(longname = 2), nams, args)
> > }
> > do.call("lowlevel", args)
> > }
> >
> > Here is a test:
> >
> >> wrapper()
> > longname = 1
> >> wrapper(longname = 34)
> > longname = 34
> >> wrapper(long = 34)
> > longname = 34
>
> Thanks, that's getting close, but it doesn't quite handle errors cleanly:
>
> > wrapper(junk=3)
> Error in lowlevel(longname = 2, "NA" = 3) :
> unused argument(s) (NA ...)
>
> It looks like I'll need something fairly elaborate.
>
> Duncan Murdoch
>
> > On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> >> I'm writing wrappers for some functions that change some of the default
> >> arguments. I'd rather not list all of the arguments for the low level
> >> functions because there are about a dozen wrapper functions, and about
> >> 20 arguments to lowlevel. Instead I'm trying something like this:
> >>
> >> lowlevel <- function(longname = 1) {
> >> cat("longname = ", longname, "\n")
> >> }
> >>
> >> wrapper <- function(...) {
> >> newargs <- list(longname = 2)
> >> newargs[names(list(...))] <- list(...)
> >> do.call("lowlevel", newargs)
> >> }
> >>
> >> This almost works:
> >>
> >> > wrapper()
> >> longname = 2
> >> > wrapper(longname = 3)
> >> longname = 3
> >>
> >> But it fails if I try to use partial argument matching:
> >>
> >> > wrapper(long=4)
> >> Error in lowlevel(longname = 2, long = 4) :
> >> unused argument(s) (long ...)
> >>
> >> because long isn't matched to longname. Is there a reasonable way to do
> >> this (e.g. using pmatch or charmatch) other than listing all the low
> >> level arguments in the argument list to wrapper?
> >>
> >> Duncan Murdoch
> >>
> >> __
> >> 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
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Uwe Ligges <[EMAIL PROTECTED]> writes: > Charles Dupont wrote: > >> I was messing around with R and I found an example R behaving oddly: >> >> a <- alist(NULL, "bob", c(3,6,2,3)) >> a >> a == 'NULL' >> a == "NULL" >> a == 'cat' >> > > > Always use is.null() to test on NULL, as in: What should I do if I want to check for the string "NULL"? > a <- list(NULL, "NULL", NA, "NA") > a == "NULL" [1] TRUE TRUE FALSE FALSE > a == "NA" [1] FALSE FALSE TRUE TRUE These are because of as.character: > as.character(a) [1] "NULL" "NULL" "NA" "NA" Yet, > as.character(NULL) character(0) > as.character(NA) [1] NA + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
I think it'd be more appropriate to use: sapply(a, "==", "NULL") or sapply(a, "==", "NA") for this case. Best, Dimitris Dimitris Rizopoulos Ph.D. Student Biostatistical Centre School of Public Health Catholic University of Leuven Address: Kapucijnenvoer 35, Leuven, Belgium Tel: +32/(0)16/336899 Fax: +32/(0)16/337015 Web: http://www.med.kuleuven.be/biostat/ http://www.student.kuleuven.be/~m0390867/dimitris.htm - Original Message - From: "Seth Falcon" <[EMAIL PROTECTED]> To: Sent: Tuesday, March 07, 2006 4:37 PM Subject: Re: [Rd] possible bug: NULL equality in lists. > Uwe Ligges <[EMAIL PROTECTED]> writes: > >> Charles Dupont wrote: >> >>> I was messing around with R and I found an example R behaving >>> oddly: >>> >>> a <- alist(NULL, "bob", c(3,6,2,3)) >>> a >>> a == 'NULL' >>> a == "NULL" >>> a == 'cat' >>> >> >> >> Always use is.null() to test on NULL, as in: > > What should I do if I want to check for the string "NULL"? > >> a <- list(NULL, "NULL", NA, "NA") > >> a == "NULL" > [1] TRUE TRUE FALSE FALSE > >> a == "NA" > [1] FALSE FALSE TRUE TRUE > > These are because of as.character: > >> as.character(a) > [1] "NULL" "NULL" "NA" "NA" > > Yet, > >> as.character(NULL) > character(0) >> as.character(NA) > [1] NA > > > > + seth > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Seth Falcon wrote: > Uwe Ligges <[EMAIL PROTECTED]> writes: > > >>Charles Dupont wrote: >> >> >>>I was messing around with R and I found an example R behaving oddly: >>> >>>a <- alist(NULL, "bob", c(3,6,2,3)) >>>a >>>a == 'NULL' >>>a == "NULL" >>>a == 'cat' >>> >> >> >>Always use is.null() to test on NULL, as in: > > > What should I do if I want to check for the string "NULL"? These are all dangerous, hence use the "safe" ways: sapply(a, is.null) sapply(a, identical, "NULL") sapply(a, is.na) sapply(a, identical, "NA") Best, Uwe > >>a <- list(NULL, "NULL", NA, "NA") > > >>a == "NULL" > > [1] TRUE TRUE FALSE FALSE > > >>a == "NA" > > [1] FALSE FALSE TRUE TRUE > > These are because of as.character: > > >>as.character(a) > > [1] "NULL" "NULL" "NA" "NA" > > Yet, > > >>as.character(NULL) > > character(0) > >>as.character(NA) > > [1] NA > > > + seth > > __ > 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] validObject does not check validity of slots
Thanks John for the reply and explanation. I sometimes use validObject
interactively, and in those circumstances it might be nice to be able
to require recursive validity checking, e.g., with an optional
argument.
Martin
John Chambers <[EMAIL PROTECTED]> writes:
> The problem is over-ambitious documentation. Recursively running
> the checks on slots for all validObject calls would be a fairly
> serious efficiency hit. Objects are checked for validity when
> created, other than as the default object, so assuming the slot
> objects to be as claimed is reasonable if they haven't been
> corrupted later on. We'll update the documentation.
>
> Validity checking is a tricky business in general. R validates new
> objects, but users can turn valid objects into invalid objects in
> cases where slots have to match in special ways (you can't apply
> validObject each time a slot changes, since the change may be part
> of a bigger computation that _will_ produce a valid object).
> Similarly, constraints on the elements can't be checked each time an
> element or subset of the object changes, if the changes have to be
> done in stages. Systems that "commit" top-level assignments can
> check then, but R does not have that distinction.
>
> Martin Morgan wrote:
>
> The documentation for validObject suggests that slots are
> checked for validity, but validObject seems only to check that the
> slot has something claiming to be correct; validObject(obj) does not
> perform the equivalent of validObject([EMAIL PROTECTED]) for slot y.
>
> This is also the second problem issue reported in
>
> http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>
> Relevant documentation, an example, and sessionInfo follow.
>
> Martin
>
> validObject package:methods R Documentation
>
> Arguments:
> ...
> Note that validity methods do not have to check validity of any
> slots or superclasses: the logic of 'validObject' ensures these
> tests are done once only.
> ...
> Details:
>
> Validity testing takes place "bottom up": first the validity of
> the object's slots, if any, is tested.
> ...
>
> setClass("foo",
> representation( x="numeric" ),
> validity = function( object ) [EMAIL PROTECTED] > 0 )
> setClass("bar",
> representation( y="foo", z="numeric" ),
> validity = function( object ) [EMAIL PROTECTED] > 0 )
> obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
>
> and then...
>
>
>
> validObject( obj )
>
>
>
> [1] TRUE
> ## invalidate [EMAIL PROTECTED]
>
>
> [EMAIL PROTECTED]@x <- -1
> validObject( [EMAIL PROTECTED] ) # right, this is not valid
>
>
>
> Error in validObject([EMAIL PROTECTED]) : invalid class "foo" object:
> FALSE
>
>
> ## [EMAIL PROTECTED] is invalid, but obj is valid?
> validObject( obj )# should be invalid?
>
>
>
> [1] TRUE
>
>
>
>
>
> sessionInfo()
>
>
>
> Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
> x86_64-unknown-linux-gnu
>
> attached base packages:
> [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
> [7] "base"
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Uwe Ligges <[EMAIL PROTECTED]> writes: > These are all dangerous, hence use the "safe" ways: > > sapply(a, is.null) > sapply(a, identical, "NULL") > sapply(a, is.na) > sapply(a, identical, "NA") Point taken, but is the behavior of as.character correct? as.character(list(NULL)) as.character(NULL) + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Uwe Ligges wrote: > Seth Falcon wrote: > > >>Uwe Ligges <[EMAIL PROTECTED]> writes: >> >> >> >>>Charles Dupont wrote: >>> >>> >>> I was messing around with R and I found an example R behaving oddly: a <- alist(NULL, "bob", c(3,6,2,3)) a a == 'NULL' a == "NULL" a == 'cat' >>> >>> >>>Always use is.null() to test on NULL, as in: >> >> >>What should I do if I want to check for the string "NULL"? > > > These are all dangerous, hence use the "safe" ways: > > sapply(a, is.null) > sapply(a, identical, "NULL") > sapply(a, is.na) > sapply(a, identical, "NA") > > Best, > Uwe For the NA list problem. It would be better if 'as.character' when converting a list when it finds a NA value to set that element to the string NA value not "NA" the string. Charles > > >>>a <- list(NULL, "NULL", NA, "NA") >> >> >>>a == "NULL" >> >>[1] TRUE TRUE FALSE FALSE >> >> >> >>>a == "NA" >> >>[1] FALSE FALSE TRUE TRUE >> >>These are because of as.character: >> >> >> >>>as.character(a) >> >>[1] "NULL" "NULL" "NA" "NA" >> >>Yet, >> >> >> >>>as.character(NULL) >> >>character(0) >> >> >>>as.character(NA) >> >>[1] NA >> >> >>+ seth >> >>__ >>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 > -- Charles Dupont Computer System Analyst School of Medicine Department of Biostatistics Vanderbilt University __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
Duncan Murdoch wrote:
> I'm writing wrappers for some functions that change some of the default
> arguments. I'd rather not list all of the arguments for the low level
> functions because there are about a dozen wrapper functions, and about
> 20 arguments to lowlevel. Instead I'm trying something like this:
>
> lowlevel <- function(longname = 1) {
>cat("longname = ", longname, "\n")
> }
>
> wrapper <- function(...) {
>newargs <- list(longname = 2)
>newargs[names(list(...))] <- list(...)
>do.call("lowlevel", newargs)
> }
>
> This almost works:
>
> > wrapper()
> longname = 2
> > wrapper(longname = 3)
> longname = 3
>
> But it fails if I try to use partial argument matching:
>
> > wrapper(long=4)
> Error in lowlevel(longname = 2, long = 4) :
> unused argument(s) (long ...)
>
> because long isn't matched to longname. Is there a reasonable way to do
> this (e.g. using pmatch or charmatch) other than listing all the low
> level arguments in the argument list to wrapper?
>
> Duncan Murdoch
If all you are doing is changing the default values of some arguments
this should work.
wrapper <- lowlevel
formals(wrapper) <- replace(formals(lowlevel), c("longname"), list(2))
Charles
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Seth Falcon wrote:
> Uwe Ligges <[EMAIL PROTECTED]> writes:
>
>>These are all dangerous, hence use the "safe" ways:
>>
>>sapply(a, is.null)
>>sapply(a, identical, "NULL")
>>sapply(a, is.na)
>>sapply(a, identical, "NA")
>
>
> Point taken, but is the behavior of as.character correct?
>
> as.character(list(NULL))
>
> as.character(NULL)
I thought about it quite a while. I think the current bahaviour is quite
OK. What should as.character do in the follwing case:
as.character(list("A", NA, NULL))
?
Note that it only can return a character vector...!
So, should it return a character vector of length 2? That's a bad idea,
if the length is reduced.
Moreover, as.character() does not get a NA or a NULL object for coercion
but an element of type list that itself conatins NA or NULL...
So if you want to convert a list to character and *keep* NA/NULL values,
you can only say:
lapply(a, as.character)
Uwe
> + seth
>
> __
> 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] Expanding partial names
Here's a slightly different approach:
lowlevel <- function(longname = 1, ...) {
cat("longname = ", longname, "\n")
}
wrapper <- function(...) {
newargs <- defaults(list(...), list(longname = 2))
do.call("lowlevel", newargs)
}
defaults <- function(x, defaults) {
if (length(x) == 0) return(defaults)
names(x) <- ifelse(is.na(pmatch(names(x), names(defaults))),
names(x), names(defaults))
c(x, defaults[setdiff(names(defaults), names(x))])
}
wrapper()
wrapper(longname=20)
wrapper(long=20)
wrapper(junk=3)
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Uwe Ligges <[EMAIL PROTECTED]> writes:
>> Point taken, but is the behavior of as.character correct?
>> as.character(list(NULL))
>> as.character(NULL)
>
>
> I thought about it quite a while. I think the current bahaviour is
> quite OK. What should as.character do in the follwing case:
>as.character(list("A", NA, NULL))
> ?
>
> Note that it only can return a character vector...!
>
> So, should it return a character vector of length 2? That's a bad
> idea, if the length is reduced.
But consistent with vectorizing a list using unlist:
unlist(list(NULL, NULL, "a"))
[1] "a"
> Moreover, as.character() does not get a NA or a NULL object for
> coercion but an element of type list that itself conatins NA or
> NULL...
In the case of NA, I think converting to "NA" should be a last
resort. Since NA is a perfectly valid element of a character vector,
it would seem to be a better choice.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug: NULL equality in lists.
Seth Falcon wrote:
> Uwe Ligges <[EMAIL PROTECTED]> writes:
>
>>>Point taken, but is the behavior of as.character correct?
>>>as.character(list(NULL))
>>>as.character(NULL)
>>
>>
>>I thought about it quite a while. I think the current bahaviour is
>>quite OK. What should as.character do in the follwing case:
>> as.character(list("A", NA, NULL))
>>?
>>
>>Note that it only can return a character vector...!
>>
>>So, should it return a character vector of length 2? That's a bad
>>idea, if the length is reduced.
>
>
> But consistent with vectorizing a list using unlist:
>
> unlist(list(NULL, NULL, "a"))
> [1] "a"
Seth, as.character() does NOT unlist anything, it converts the *list*
objects to character, the one element case might be a to trivial
example, instead consider:
> as.character(list(c("a", "b"), NULL, c(NA, NULL, 2)))
[1] "c(\"a\", \"b\")" "NULL""c(NA, 2)"
I think you simply should not apply as.character on a list as a whole in
order to get what you are expecting ...
Best,
Uwe
>>Moreover, as.character() does not get a NA or a NULL object for
>>coercion but an element of type list that itself conatins NA or
>>NULL...
>
>
> In the case of NA, I think converting to "NA" should be a last
> resort. Since NA is a perfectly valid element of a character vector,
> it would seem to be a better choice.
> __
> 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] Expanding partial names
On 3/7/2006 12:08 PM, Charles Dupont wrote:
> Duncan Murdoch wrote:
>> I'm writing wrappers for some functions that change some of the default
>> arguments. I'd rather not list all of the arguments for the low level
>> functions because there are about a dozen wrapper functions, and about
>> 20 arguments to lowlevel. Instead I'm trying something like this:
>>
>> lowlevel <- function(longname = 1) {
>>cat("longname = ", longname, "\n")
>> }
>>
>> wrapper <- function(...) {
>>newargs <- list(longname = 2)
>>newargs[names(list(...))] <- list(...)
>>do.call("lowlevel", newargs)
>> }
>>
>> This almost works:
>>
>> > wrapper()
>> longname = 2
>> > wrapper(longname = 3)
>> longname = 3
>>
>> But it fails if I try to use partial argument matching:
>>
>> > wrapper(long=4)
>> Error in lowlevel(longname = 2, long = 4) :
>> unused argument(s) (long ...)
>>
>> because long isn't matched to longname. Is there a reasonable way to do
>> this (e.g. using pmatch or charmatch) other than listing all the low
>> level arguments in the argument list to wrapper?
>>
>> Duncan Murdoch
>
> If all you are doing is changing the default values of some arguments
> this should work.
>
> wrapper <- lowlevel
> formals(wrapper) <- replace(formals(lowlevel), c("longname"), list(2))
Thanks for the suggestion, but the calculation of the new defaults is
more involved than my example indicated. I really need to do some
computation within the wrapper to come up with the new defaults.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
> I'm writing wrappers for some functions that change some of the default
> arguments. I'd rather not list all of the arguments for the low level
> functions because there are about a dozen wrapper functions, and about
> 20 arguments to lowlevel. Instead I'm trying something like this:
>
> lowlevel <- function(longname = 1) {
>cat("longname = ", longname, "\n")
> }
>
> wrapper <- function(...) {
>newargs <- list(longname = 2)
>newargs[names(list(...))] <- list(...)
>do.call("lowlevel", newargs)
> }
>
> This almost works:
>
> > wrapper()
> longname = 2
> > wrapper(longname = 3)
> longname = 3
>
> But it fails if I try to use partial argument matching:
>
> > wrapper(long=4)
> Error in lowlevel(longname = 2, long = 4) :
> unused argument(s) (long ...)
>
> because long isn't matched to longname. Is there a reasonable way to do
> this (e.g. using pmatch or charmatch) other than listing all the low
> level arguments in the argument list to wrapper?
One trick I often use that is different from any of the suggestions I have seen
so far (and is more transparent IMO) is the following:
lowlevel <- function(longname = 1) {
cat("longname = ", longname, "\n")
}
wrapper <- function(...) {
newArgs <-
function(longname = 2, ...)
list(longname = longname,
...)
do.call("lowlevel", newArgs(...))
}
which gives:
> wrapper()
longname = 2
> wrapper(longname = 3)
longname = 3
> wrapper(long=20)
longname = 20
> wrapper(junk=3)
Error in lowlevel(longname = 2, junk = 3) :
unused argument(s) (junk ...)
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R started in terminal shell script or ESS steps on LD_LIBRARY_PATH?
Hi all,
Just noted this behavior in the past couple of days, where if R is
started in a shell script such as:
gnome-terminal [-e][-x] R
or in ESS (version 5.2.12 with Emacs or XEmacs), the LD_LIBRARY_PATH
environment variable is not properly appended to, resulting in the loss
of the pre-start value.
This is using R Version 2.2.1 Patched (2006-02-28 r37448) on FC4.
I noted this when attempting to access an Oracle 10g server using RODBC
(version 1.1-5) and to the best of my recollection, this is a new
problem.
It took me a while to figure this out and was about to send an e-mail to
r-sig-db since I was having trouble connecting using odbcConnect(), when
I noted the problem with LD_LIBRARY_PATH. I noted this quite by accident
as I was writing the e-mail to r-sig-db.
I was on the verge of mental vapor lock with this, so if I missed a
documented change in behavior, my apologies. In looking at the R startup
script, it seems appropriate in terms of appending to the existing
value. So it seems that this is being altered elsewhere presumably.
In the two cases I note above, I get:
> Sys.getenv("LD_LIBRARY_PATH")
LD_LIBRARY_PATH
"/usr/local/lib/R/lib:/usr/local/lib:/usr/X11R6/lib"
whereas the pre-start value is:
LD_LIBRARY_PATH=/usr/lib/oracle/10.2.0.1/client/lib
Importantly, if I start a gnome-terminal session and then start R from
the command line, I get:
> Sys.getenv("LD_LIBRARY_PATH")
LD_LIBRARY_PATH
"/usr/local/lib/R/lib:/usr/local/lib:/usr/X11R6/lib:/usr/lib/oracle/10.2.0.1/client/lib"
In this case, I can use odbcConnect() to the Oracle server and it works
the first time, every time.
This suggests to me some type of problem in the inheritance of the
pre-session environment in the two former cases, but again, I may be
missing something.
Even if I try:
LD_LIBRARY_PATH <- Sys.getenv("LD_LIBRARY_PATH")
Sys.putenv(LD_LIBRARY_PATH = paste(LD_LIBRARY_PATH,
"/usr/lib/oracle/10.2.0.1/client/lib", sep = ":"))
and then:
> Sys.getenv("LD_LIBRARY_PATH")
LD_LIBRARY_PATH
"/usr/local/lib/R/lib:/usr/local/lib:/usr/X11R6/lib:/usr/lib/oracle/10.2.0.1/client/lib"
I still cannot get odbcConnect() to work. I still get the error that I
was getting in the two initial R startup situations:
Warning messages:
1: [RODBC] ERROR: state 01000, code 0, message [unixODBC][Driver
Manager]Can't open lib
'/usr/lib/oracle/10.2.0.1/client/lib/libsqora.so.10.1' :
libclntsh.so.10.1: cannot open shared object file: No such file or
directory
2: ODBC connection failed in: odbcDriverConnect(st, case = case,
believeNRows = believeNRows)
The above error is what has been driving me nuts for the past two days,
since clearly these files are present and it works in R from the
gnome-terminal command line and when using the sql*plus instant client
directly. The LD_LIBRARY_PATH issue is the only one that I have noted
that appears to be different.
Any ideas on this? Did I miss a change someplace?
Thanks for any insights.
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] validObject does not check validity of slots
Martin Morgan wrote:
>Thanks John for the reply and explanation. I sometimes use validObject
>interactively, and in those circumstances it might be nice to be able
>to require recursive validity checking, e.g., with an optional
>argument.
>
>
Sounds reasonable. After some complicated replacements of slots at
various levels, it would make sense to do a more complete test, and it
does have to be done explicitly.
It looks straightforward to have an argument complete= that defaults to
FALSE; if so, I'll add it to r-devel.
>Martin
>
>John Chambers <[EMAIL PROTECTED]> writes:
>
>
>
>>The problem is over-ambitious documentation. Recursively running
>>the checks on slots for all validObject calls would be a fairly
>>serious efficiency hit. Objects are checked for validity when
>>created, other than as the default object, so assuming the slot
>>objects to be as claimed is reasonable if they haven't been
>>corrupted later on. We'll update the documentation.
>>
>>Validity checking is a tricky business in general. R validates new
>>objects, but users can turn valid objects into invalid objects in
>>cases where slots have to match in special ways (you can't apply
>>validObject each time a slot changes, since the change may be part
>>of a bigger computation that _will_ produce a valid object).
>>Similarly, constraints on the elements can't be checked each time an
>>element or subset of the object changes, if the changes have to be
>>done in stages. Systems that "commit" top-level assignments can
>>check then, but R does not have that distinction.
>>
>>Martin Morgan wrote:
>>
>> The documentation for validObject suggests that slots are
>>checked for validity, but validObject seems only to check that the
>>slot has something claiming to be correct; validObject(obj) does not
>>perform the equivalent of validObject([EMAIL PROTECTED]) for slot y.
>>
>>This is also the second problem issue reported in
>>
>>http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>>
>>Relevant documentation, an example, and sessionInfo follow.
>>
>>Martin
>>
>>validObject package:methods R Documentation
>>
>>Arguments:
>> ...
>> Note that validity methods do not have to check validity of any
>> slots or superclasses: the logic of 'validObject' ensures these
>> tests are done once only.
>> ...
>>Details:
>>
>> Validity testing takes place "bottom up": first the validity of
>> the object's slots, if any, is tested.
>> ...
>>
>>setClass("foo",
>> representation( x="numeric" ),
>> validity = function( object ) [EMAIL PROTECTED] > 0 )
>>setClass("bar",
>> representation( y="foo", z="numeric" ),
>> validity = function( object ) [EMAIL PROTECTED] > 0 )
>>obj <- new( "bar", y = new( "foo", x=1 ), z = 1 )
>>
>>and then...
>>
>>
>>
>>validObject( obj )
>>
>>
>>
>> [1] TRUE
>>## invalidate [EMAIL PROTECTED]
>>
>>
>>[EMAIL PROTECTED]@x <- -1
>>validObject( [EMAIL PROTECTED] ) # right, this is not valid
>>
>>
>>
>> Error in validObject([EMAIL PROTECTED]) : invalid class "foo" object:
>> FALSE
>>
>>
>>## [EMAIL PROTECTED] is invalid, but obj is valid?
>>validObject( obj )# should be invalid?
>>
>>
>>
>> [1] TRUE
>>
>>
>>
>>
>>
>>sessionInfo()
>>
>>
>>
>> Version 2.3.0 Under development (unstable) (2006-03-03 r37471)
>>x86_64-unknown-linux-gnu
>>
>>attached base packages:
>>[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
>>[7] "base"
>>
>>__
>>R-devel@r-project.org mailing list
>>https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>
>__
>R-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] validObject does not check validity of slots
> "JMC" == John Chambers <[EMAIL PROTECTED]>
> on Tue, 07 Mar 2006 16:33:59 -0500 writes:
JMC> Martin Morgan wrote:
>> Thanks John for the reply and explanation. I sometimes
>> use validObject interactively, and in those circumstances
>> it might be nice to be able to require recursive validity
>> checking, e.g., with an optional argument.
>>
>>
JMC> Sounds reasonable. After some complicated replacements
JMC> of slots at various levels, it would make sense to do a
JMC> more complete test, and it does have to be done
JMC> explicitly.
JMC> It looks straightforward to have an argument complete=
JMC> that defaults to FALSE; if so, I'll add it to r-devel.
I agree with the other Martin that this would be "nice" to have.
Also for debugging purposes, or as "watch point" when developing
new functionality.
Martin Maechler, ETH Zurich
>> Martin
>>
>> John Chambers <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>> The problem is over-ambitious documentation.
>>> Recursively running the checks on slots for all
>>> validObject calls would be a fairly serious efficiency
>>> hit. Objects are checked for validity when created,
>>> other than as the default object, so assuming the slot
>>> objects to be as claimed is reasonable if they haven't
>>> been corrupted later on. We'll update the
>>> documentation.
>>>
>>> Validity checking is a tricky business in general. R
>>> validates new objects, but users can turn valid objects
>>> into invalid objects in cases where slots have to match
>>> in special ways (you can't apply validObject each time a
>>> slot changes, since the change may be part of a bigger
>>> computation that _will_ produce a valid object).
>>> Similarly, constraints on the elements can't be checked
>>> each time an element or subset of the object changes, if
>>> the changes have to be done in stages. Systems that
>>> "commit" top-level assignments can check then, but R
>>> does not have that distinction.
>>>
>>> Martin Morgan wrote:
>>>
>>> The documentation for validObject suggests that slots
>>> are checked for validity, but validObject seems only to
>>> check that the slot has something claiming to be
>>> correct; validObject(obj) does not perform the
>>> equivalent of validObject([EMAIL PROTECTED]) for slot y.
>>>
>>> This is also the second problem issue reported in
>>>
>>> http://tolstoy.newcastle.edu.au/R/devel/05/03/0151.html
>>>
>>> Relevant documentation, an example, and sessionInfo
>>> follow.
>>>
>>> Martin
>>>
>>> validObject package:methods R Documentation
>>>
>>> Arguments: ... Note that validity methods do not have
>>> to check validity of any slots or superclasses: the
>>> logic of 'validObject' ensures these tests are done once
>>> only. ... Details:
>>>
>>> Validity testing takes place "bottom up": first the
>>> validity of the object's slots, if any, is tested. ...
>>>
>>> setClass("foo", representation( x="numeric" ), validity
>>> = function( object ) [EMAIL PROTECTED] > 0 ) setClass("bar",
>>> representation( y="foo", z="numeric" ), validity =
>>> function( object ) [EMAIL PROTECTED] > 0 ) obj <- new( "bar", y =
>>> new( "foo", x=1 ), z = 1 )
>>>
>>> and then...
>>>
>>>
>>>
>>> validObject( obj )
>>>
>>>
>>>
>>> [1] TRUE ## invalidate [EMAIL PROTECTED]
>>>
>>>
>>> [EMAIL PROTECTED]@x <- -1 validObject( [EMAIL PROTECTED] ) # right,
this is not
>>> valid
>>>
>>>
>>>
>>> Error in validObject([EMAIL PROTECTED]) : invalid class "foo"
>>> object: FALSE
>>>
>>>
>>> ## [EMAIL PROTECTED] is invalid, but obj is valid? validObject( obj
>>> ) # should be invalid?
>>>
>>>
>>>
>>> [1] TRUE
>>>
>>>
>>>
>>>
>>>
>>> sessionInfo()
>>>
>>>
>>>
>>> Version 2.3.0 Under development (unstable) (2006-03-03
>>> r37471) x86_64-unknown-linux-gnu
>>>
>>> attached base packages: [1] "methods" "stats" "graphics"
>>> "grDevices" "utils" "datasets" [7] "base"
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>>
>>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
JMC>[[alternative HTML version deleted]]
JMC> __
JMC> R-devel@r-project.org mailing list
JMC> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
htt
[Rd] SVN troubles
Dear r-devel, Sorry to trouble the list with this, but I've been beating my head against the wall trying to figure out what's wrong. When I try to connect to the R SVN server, I get the following message: ([EMAIL PROTECTED]):~/src/R$ svn co https://svn.r-project.org/R/trunk r-devel svn: PROPFIND request failed on '/R/trunk' svn: PROPFIND of '/R/trunk': SSL negotiation failed: SSL error: bad signature (https://svn.r-project.org) on other boxes, things are fine. I've tried two different versions of svn on this box, 1.2.3 and 1.3.0, to no avail. Any suggestions would be greatly appreciated. Perhaps SSL is broken here, but I can't seem to figure out how to get any better diagnostics for this. Thanks, Cyrus __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN troubles
Cyrus Harmon <[EMAIL PROTECTED]> writes: > Dear r-devel, > > Sorry to trouble the list with this, but I've been beating my head > against the wall trying to figure out what's wrong. When I try to > connect to the R SVN server, I get the following message: > > ([EMAIL PROTECTED]):~/src/R$ svn co https://svn.r-project.org/R/trunk r-devel > svn: PROPFIND request failed on '/R/trunk' > svn: PROPFIND of '/R/trunk': SSL negotiation failed: SSL error: bad > signature (https://svn.r-project.org) You could try going to that URL with a web browser on that system. You could also see what is inside your ~/.subversion directory on that system. Perhaps a cached cert is invalid and preventing ssl auth. + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Expanding partial names
On 3/7/2006 2:00 PM, Deepayan Sarkar wrote:
>
> On 3/7/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> I'm writing wrappers for some functions that change some of the default
>> arguments. I'd rather not list all of the arguments for the low level
>> functions because there are about a dozen wrapper functions, and about
>> 20 arguments to lowlevel. Instead I'm trying something like this:
>>
>> lowlevel <- function(longname = 1) {
>>cat("longname = ", longname, "\n")
>> }
>>
>> wrapper <- function(...) {
>>newargs <- list(longname = 2)
>>newargs[names(list(...))] <- list(...)
>>do.call("lowlevel", newargs)
>> }
>>
>> This almost works:
>>
>> > wrapper()
>> longname = 2
>> > wrapper(longname = 3)
>> longname = 3
>>
>> But it fails if I try to use partial argument matching:
>>
>> > wrapper(long=4)
>> Error in lowlevel(longname = 2, long = 4) :
>> unused argument(s) (long ...)
>>
>> because long isn't matched to longname. Is there a reasonable way to do
>> this (e.g. using pmatch or charmatch) other than listing all the low
>> level arguments in the argument list to wrapper?
>
> One trick I often use that is different from any of the suggestions I have
> seen so far (and is more transparent IMO) is the following:
Thanks, this is a nice idea. It looks as though it would combine well
with Charles Duponts' suggestion to change the formals, i.e. I could
have a generic version of your newArgs function, then change the formals
and the body to match the pattern you used.
One thing I'd like is to be able to put the new defaults in a list,
because this code is going to show up in about a dozen places, and I
don't want to have to edit all of them when the arg list of the low
level function changes. So really I want something like
newArgs(..., newDefaults)
where newDefaults is a tagged list (e.g. list(longname = 2) for the
example below), and the return value is a list containing all the names
in newDefaults, perhaps with their values modified according to the args
passed in ... .
In the actual use newDefaults would be the result of a function call
(the user will have made some configuration choices and I want those to
be used as defaults to another function) but that's not so important
here. I'd like the wrapper to be a bit like par(), though I notice that
par() doesn't accept partial name matching so maybe I'm worrying about
something I shouldn't.
Duncan Murdoch
>
>
> lowlevel <- function(longname = 1) {
>cat("longname = ", longname, "\n")
> }
>
> wrapper <- function(...) {
> newArgs <-
> function(longname = 2, ...)
> list(longname = longname,
> ...)
> do.call("lowlevel", newArgs(...))
> }
>
> which gives:
>
>> wrapper()
> longname = 2
>> wrapper(longname = 3)
> longname = 3
>> wrapper(long=20)
> longname = 20
>> wrapper(junk=3)
> Error in lowlevel(longname = 2, junk = 3) :
> unused argument(s) (junk ...)
>
> -Deepayan
>
> __
> 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] Wishlist - Give R a name that shows up in search engines...
On 7 March 2006 at 10:55, Hin-Tak Leung wrote: | I have given up on "R" with any topic on Google quite some time | ago (because bits from fragmented postscript/pdf files show up, | for example) - but using "r-devel" with topic normally gives me | enough. YMMV. Nobody seems to have mentioned the RSiteSearch() function which automagically restrict the search to domains relevant to the contect of "our" use of the letter R. I quite like that as I tend to have an R prompt open when I am puzzled by R questions ... Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Wishlist - Give R a name that shows up in search engines ...
From: Dirk Eddelbuettel > > On 7 March 2006 at 10:55, Hin-Tak Leung wrote: > | I have given up on "R" with any topic on Google quite some time ago > | (because bits from fragmented postscript/pdf files show up, for > | example) - but using "r-devel" with topic normally gives me enough. > | YMMV. > > Nobody seems to have mentioned the RSiteSearch() function > which automagically restrict the search to domains relevant > to the contect of "our" use of the letter R. I quite like > that as I tend to have an R prompt open when I am puzzled by > R questions ... My guess is that people were hoping to find things outside of what Jon made available or what's on or linked from www.r-project.org. I believe that's not going to be very productive (at least for now). I don't think there's a whole lot of things related to R that isn't found in those two places. Andy > Dirk > > -- > Hell, there are no rules here - we're trying to accomplish something. > -- Thomas A. Edison > > __ > 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] Expanding partial names
Okay, here's my effort based on Deepayan's and Charles' ideas. The
newArgs function is not what I'd call transparent, but I like the way
the wrapper looks.
> newArgs <- function(..., Params) {
+ f <- function(...) list(...)
+ formals(f) <- c(Params, formals(f))
+ b <- as.list(body(f))
+ body(f) <- as.call(c(b[1], names, b[-1]))
+ f(...)
+ }
>
> lowlevel <- function(longname = 1) {
+ cat("longname = ", longname, "\n")
+ }
>
> newDefaults <- list(longname=2)
>
> wrapper <- function (...)
+ do.call("lowlevel", newArgs(..., Params=newDefaults))
newArgs sets up f to look like
function (longname = 2, ...) list(longname = longname, ...)
and then calls it. The thing I like about this, as opposed to using
pmatch, is that I'm sure the partial matching is what's used by R's
argument matching, whereas that's only pretty likely with pmatch.
I also sort of like these lines:
+ names <- as.list(names(Params))
+ names(names) <- names
+ names <- lapply(names, as.name)
but maybe I should have named Params as names, so they looked like this:
+ names <- as.list(names(names))
+ names(names) <- names
+ names <- lapply(names, as.name)
And of course I like the fact that this seems to work, but we've seen
several versions that do that:
> wrapper()
longname = 2
> wrapper(longname=3)
longname = 3
> wrapper(long=3)
longname = 3
> wrapper(long=20)
longname = 20
> wrapper(junk=20)
Error in lowlevel(longname = 2, junk = 20) :
unused argument(s) (junk ...)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] SVN troubles
Just thought y'all might like to know that the cause of my trouble was that the openssl libraries currently in fink (for MacOS X on Intel) seem to be broken. Using the system supplied openssl libraries to build svn seems to fix the problem. Thanks and sorry for the noise. Cyrus On Mar 7, 2006, at 3:46 PM, Seth Falcon wrote: > Cyrus Harmon <[EMAIL PROTECTED]> writes: > >> Dear r-devel, >> >> Sorry to trouble the list with this, but I've been beating my head >> against the wall trying to figure out what's wrong. When I try to >> connect to the R SVN server, I get the following message: >> >> ([EMAIL PROTECTED]):~/src/R$ svn co https://svn.r-project.org/R/trunk r- >> devel >> svn: PROPFIND request failed on '/R/trunk' >> svn: PROPFIND of '/R/trunk': SSL negotiation failed: SSL error: bad >> signature (https://svn.r-project.org) > > You could try going to that URL with a web browser on that system. > You could also see what is inside your ~/.subversion directory on that > system. Perhaps a cached cert is invalid and preventing ssl auth. > > + seth > > __ > 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
