> "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 lo
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 t
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
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
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 (
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 s
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 multip
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 <- fu
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 '
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
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 NUL
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.c
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(f
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
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)1
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 te
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 d
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)
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 == 'c
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 someth
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.char
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)
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.charac
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 fo
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
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 low
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
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 replaceme
> "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 r
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: PROP
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 c
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 w
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 R
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
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))
+
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,
36 matches
Mail list logo
