Re: [Rd] single assignment affecting multiple sub-structures (PR#7924)

[Tony Plate]

Yes, actually, I have had code using do.call() that returns the result I 
want working for years.  However, I've been trying to reduce the memory 
usage of my code, and I discovered that in S-PLUS, do.call() appears to 
make a extra copy of its arguments.  When the arguments are very large, 
this can be important.  I found that by constructing a call like the one 
below, and eval()ing it, S-PLUS would not make unnecessary copies of the 
arguments.

However, when I tried the same code in R, I found the bug that I 
described below.

-- Tony Plate

Douglas Bates wrote:
> I hesitate to make such as simplistic suggestion but have you
> considered using do.call to generate the call?
> 
> On 6/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 
>>I'm trying to create a language structure that is a call to a function
>>with a number of arguments that is only known at run time.  I do this by
>>using repeated indices to expand out a call with a single argument.
>>However, when I change one of the arguments, all are changed.
>>
>>I don't see the same behavior when I initially create a call with
>>multiple arguments.
>>
>>Even more strangely, calling identical(call1, call2) before any attempts
>>to modify the structures changes the subsequent behavior to be correct.
>>
>>[If there are better methods to create and modify calls, please let me
>>know!]
>>
>> > # Example of commands that give incorrect results
>> > call1 <- Quote(f(arg[[1]], arg[[1]], arg[[1]]))
>> > call2 <- Quote(f(arg[[1]]))[c(1,2,2,2)]
>> > call1
>>f(arg[[1]], arg[[1]], arg[[1]])
>> > call2
>>f(arg[[1]], arg[[1]], arg[[1]])
>> > call1[[3]][[3]] <- 2
>> > call2[[3]][[3]] <- 2
>> > call1
>>f(arg[[1]], arg[[2]], arg[[1]])
>> > # note that all the arguments of call2 have changed!
>> > call2
>>f(arg[[2]], arg[[2]], arg[[2]])
>> > identical(call1, call2)
>>[1] FALSE
>> >
>> > # if we do 'identical(call1, call2)' directly
>> > # after creation, then everything behaves correctly !??
>> > call1 <- Quote(f(arg[[1]], arg[[1]], arg[[1]]))
>> > call2 <- Quote(f(arg[[1]]))[c(1,2,2,2)]
>> > identical(call1, call2)
>>[1] TRUE
>> > call1
>>f(arg[[1]], arg[[1]], arg[[1]])
>> > call2
>>f(arg[[1]], arg[[1]], arg[[1]])
>> > call1[[3]][[3]] <- 2
>> > call2[[3]][[3]] <- 2
>> > call1
>>f(arg[[1]], arg[[2]], arg[[1]])
>> > call2
>>f(arg[[1]], arg[[2]], arg[[1]])
>> > identical(call1, call2)
>>[1] TRUE
>> >
>> > # The same thing happens when the call is created using 'call()'
>> > call3 <- call("f", call("[[", as.name("arg"), 1))[c(1,2,2,2)]
>> > call3
>>f(arg[[1]], arg[[1]], arg[[1]])
>> > call3[[3]][[3]] <- 2
>> > call3
>>f(arg[[2]], arg[[2]], arg[[2]])
>> >
>> > version
>>  _
>>platform i386-pc-mingw32
>>arch i386
>>os   mingw32
>>system   i386, mingw32
>>status
>>major2
>>minor1.0
>>year 2005
>>month04
>>day  18
>>language R
>> >
>>
>>
>>I also see the same behavior in the development release of R:
>> > version
>>  _
>>platform i386-pc-mingw32
>>arch i386
>>os   mingw32
>>system   i386, mingw32
>>status   Under development (unstable)
>>major2
>>minor2.0
>>year 2005
>>month06
>>day  07
>>svn rev  34588
>>language R
>> >
>>
>>-- Tony Plate
>>
>>__
>>R-devel@stat.math.ethz.ch 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] octonions

[Tony Plate]

It's reasonably easy to define an S3 class for vectors (e.g., 
"octonion") and then define operator methods (for all operators other 
than matrix operators) to do what you want with that class.  To do this 
you need to define a function Ops.octonion.  All of this is easily done 
in pure R. I just wrote a package that does just that for a vector class 
with a different algebra (I can send you a copy if you could use any 
hints on those aspects).  I'm not sure of the best way of defining a 
method for '%*%'.   I think it's possible to use setMethod() to define a 
method for '%*%', but I haven't played with that much (my initial 
attempts have worked, but warnings have been generated by setMethod).

-- Tony Plate

Robin Hankin wrote:
> Hi
> 
> I  thought it would be fun to develop R functionality for
> the octonions (there is  already some work on quaternions).
> 
> The octonions are an 8 dimensional algebra over the reals, so an  
> octonion
> may nicely be represented as a real vector of length 8.  Applications
> are many and varied, mostly quantum mechanics.
> 
> I would like to develop some R functionality in this area.
> My first problem is how to get (eg) a matrix whose entries are  
> octonions?
> It would  be nice for a %*% b to behave sensibly when a and b are
> matrices with octonion elements.
> 
> Octonions  are not associative [that is,
> x*(y*z) != (x*y)*z ] or commutative [x*y != y*x].
> One usually sees an 8-by-8 table that gives the products.
> 
> At this stage, I'm polling for ideas on overall structure.
> Would a package be the best way forward?  Or
> writing an equivalent of complex.c? Or is there
> another approach that would be better? The
> basic multiplication table is easily implemented in C,
> and I now have an (untested) R function OctonionProduct(. , .)
> that multiplies two octonions; but I
> am struggling to see how to make this play nicely with R: it's not
> obvious how to make octonion matrices multiply as they should,
> in the same way that (eg) complex matrices do.
> 
> Perhaps we could define "*" and "/"  appropriately for vectors of class
> "octonion" (if such a thing makes sense):  or is there a better
> way?  Also, Mod(), Re(), and perhaps
> Conj() would have to be generalized to work with octonions.
> 
> 
> comments please!
> 
> 
> --
> Robin Hankin
> Uncertainty Analyst
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
>   tel  023-8059-7743
> 
> __
> 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] unvectorized option for outer()

[Tony Plate]

[following on from a thread on R-help, but my post here seems more 
appropriate to R-devel]

Would a patch to make outer() work with non-vectorized functions be
considered?  It seems to come up moderately often on the list, which
probably indicates that many many people get bitten by the same
incorrect expectation, despite the documentation and the FAQ entry.  It
looks pretty simple to modify outer() appropriately: one extra function
argument and an if-then-else clause to call mapply(FUN, ...) instead of
calling FUN directly.

Here's a function demonstrating this:

outer2 <- function (X, Y, FUN = "*", ..., VECTORIZED=TRUE)
{
 no.nx <- is.null(nx <- dimnames(X <- as.array(X)))
 dX <- dim(X)
 no.ny <- is.null(ny <- dimnames(Y <- as.array(Y)))
 dY <- dim(Y)
 if (is.character(FUN) && FUN == "*") {
 robj <- as.vector(X) %*% t(as.vector(Y))
 dim(robj) <- c(dX, dY)
 }
 else {
 FUN <- match.fun(FUN)
 Y <- rep(Y, rep.int(length(X), length(Y)))
 if (length(X) > 0)
 X <- rep(X, times = ceiling(length(Y)/length(X)))
 if (VECTORIZED)
 robj <- FUN(X, Y, ...)
 else
 robj <- mapply(FUN, X, Y, MoreArgs=list(...))
 dim(robj) <- c(dX, dY)
 }
 if (no.nx)
 nx <- vector("list", length(dX))
 else if (no.ny)
 ny <- vector("list", length(dY))
 if (!(no.nx && no.ny))
 dimnames(robj) <- c(nx, ny)
 robj
}
# Some examples
f <- function(x, y, p=1) {cat("in f\n"); (x*y)^p}
outer2(1:2, 3:5, f, 2)
outer2(numeric(0), 3:5, f, 2)
outer2(1:2, numeric(0), f, 2)
outer2(1:2, 3:5, f, 2, VECTORIZED=F)
outer2(numeric(0), 3:5, f, 2, VECTORIZED=F)
outer2(1:2, numeric(0), f, 2, VECTORIZED=F)

# Output on examples
> f <- function(x, y, p=1) {cat("in f\n"); (x*y)^p}
> outer2(1:2, 3:5, f, 2)
in f
  [,1] [,2] [,3]
[1,]9   16   25
[2,]   36   64  100
> outer2(numeric(0), 3:5, f, 2)
in f
  [,1] [,2] [,3]
> outer2(1:2, numeric(0), f, 2)
in f

[1,]
[2,]
> outer2(1:2, 3:5, f, 2, VECTORIZED=F)
in f
in f
in f
in f
in f
in f
  [,1] [,2] [,3]
[1,]9   16   25
[2,]   36   64  100
> outer2(numeric(0), 3:5, f, 2, VECTORIZED=F)
  [,1] [,2] [,3]
> outer2(1:2, numeric(0), f, 2, VECTORIZED=F)

[1,]
[2,]
>

If a patch to add this feature would be considered, I'd be happy to
submit one (including documentation).  If so, and if there are any
potential traps I should bear in mind, please let me know!

-- Tony Plate

Rau, Roland wrote:
> Dear all,
> 
> a big thanks to Thomas Lumley, James Holtman and Tony Plate for their
> answers. They all pointed in the same direction => I need a vectorized
> function to be applied. Hence, I will try to work with a 'wrapper'
> function as described in the FAQ.
> 
> Thanks again,
> Roland
> 
> 
> 
>>-Original Message-
>>From: Thomas Lumley [mailto:[EMAIL PROTECTED] 
>>Sent: Thursday, October 27, 2005 11:39 PM
>>To: Rau, Roland
>>Cc: r-help@stat.math.ethz.ch
>>Subject: Re: [R] outer-question
>>
>>
>>You want FAQ 7.17 Why does outer() behave strangely with my function?
>>
>>  -thomas
>>
>>On Thu, 27 Oct 2005, Rau, Roland wrote:
>>
>>
>>>Dear all,
>>>
>>>This is a rather lengthy message, but I don't know what I 
>>
>>made wrong in
>>
>>>my real example since the simple code works.
>>>I have two variables a, b and a function f for which I would like to
>>>calculate all possible combinations of the values of a and b.
>>>If f is multiplication, I would simply do:
>>>
>>>a <- 1:5
>>>b <- 1:5
>>>outer(a,b)
>>>
>>>## A bit more complicated is this:
>>>f <- function(a,b,d) {
>>> return(a*b+(sum(d)))
>>>}
>>>additional <- runif(100)
>>>outer(X=a, Y=b, FUN=f, d=additional)
>>>
>>>## So far so good. But now my real example. I would like to plot the
>>>## log-likelihood surface for two parameters alpha and beta of
>>>## a Gompertz distribution with given data
>>>
>>>### I have a function to generate random-numbers from a
>>>Gompertz-Distribution
>>>### (using the 'inversion method')
>>>
>>>random.gomp <- function(n, alpha, beta) {
>>>   return( (log(1-(beta/alpha*log(1-runif(n)/beta)
>>>}
>>>
>>>## Now I generate some 'lifetimes'
>>>no.people <- 1000
>>>al <- 0.1
>>>bet <- 0.1
>>>lifetimes <- random.gomp(n=no.people, alpha=al, beta=bet

Re: [Rd] [R] unvectorized option for outer()

[Tony Plate]

When I read the preface to The Blue Book (The New S Language, Becker, 
Chambers & Wilks) I see comments along the lines of "high-level 
language", "primary goal of the S environment is to enable and encourage 
good data analysis", etc.  While vectorization is a great feature of S 
(and R), I don't see it, or programming efficiency, mentioned there at all.

Nonetheless, Peter's suggestion of a general Vectorize() function is 
intriguing, and could be useful with other functions that trip users up 
in the same way.  (Also, I do apprecicate Peter pointing out that not 
all functions vectorize naturally, as in his example density 
calculations over grids of parameters).

So, here's a first pass at a general Vectorize() function:

Vectorize <- function(FUN, vectorize.args) {
 if (!all(is.element(vectorize.args, names(formals(FUN)
 stop("some args to vectorize are not args of FUN")
 FUNV <- eval(substitute(function(x, ...) mapply(FUN, x, 
MoreArgs=list(...)), list(FUN=FUN)))
 formals(FUNV) <- formals(FUNV)[c(rep(1, length(vectorize.args)), 2)]
 names(formals(FUNV))[seq(along=vectorize.args)] <- vectorize.args
 body(FUNV) <- body(FUNV)[c(1, 2, rep(3, length(vectorize.args)), 4)]
 body(FUNV)[seq(3,len=length(vectorize.args))] <- 
lapply(vectorize.args, as.name)
 FUNV
}

ssd <- function(A,alpha,Y,t) sum((Y - A*exp(-alpha*t))2)
# SSD is a vectorized version of ssd
SSD <- function(Avec, alphavec, ...) mapply(ssd, Avec, alphavec, 
MoreArgs=list(...))
# Vectorize(ssd, c("A", "alpha")) should produce
# function(A, alpha, ...) mapply(ssd, A, alpha, MoreArgs=list(...))
Y <- 1:5; t <- 3
outer(1:3, 1:2, SSD, Y, t)
outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)

 > # transcript of running the above commands
 > Vectorize(ssd, c("A", "alpha"))
function (A, alpha, ...)
mapply(function (A, alpha, Y, t)
sum((Y - A * exp(-alpha * t))^2), A, alpha, MoreArgs = list(...))

 > Y <- 1:5; t <- 3
 > outer(1:3, 1:2, SSD, Y, t)
  [,1] [,2]
[1,] 53.51878 54.92567
[2,] 52.06235 54.85140
[3,] 50.63071 54.77719
 > outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)
  [,1] [,2]
[1,] 53.51878 54.92567
[2,] 52.06235 54.85140
[3,] 50.63071 54.77719
 >

[There are a couple of minor design issues around syntax -- what is the 
best way of specifying the arguments to vectorize? (e.g., what about an 
interface that allowed Vectorize(ssd ~ A * alpha)?), and should the 
function name rather than the definition appear in the result of 
Vectorize()?  But those are issues of secondary importance.]

I have to confess I don't really understand how environments work with 
functions, so I don't know if this Vectorize() function will work in 
general.  What is the appropriate environment for returned value of 
Vectorize()?  Is this approach to creating a Vectorize() function on the 
right tack at all?  Any other improvements or fixes?

-- Tony Plate


Peter Dalgaard wrote:
> Thomas Lumley <[EMAIL PROTECTED]> writes:
> 
> 
>>On Sun, 30 Oct 2005, Jonathan Rougier wrote:
>>
>>
>>>I'm not sure about this.  Perhaps I am a dinosaur, but my feeling is
>>>that if people are writing functions in R that might be subject to
>>>simple operations like outer products, then they ought to be writing
>>>vectorised functions!
>>
>>I would agree.  How about an oapply() function that does multiway (rather 
>>than just two-way) outer products.  Basing the name on "apply" would 
>>emphasize the similarity to other flexible, not particularly optimized 
>>second-order functions.
> 
> 
> In fairness, it should probably be said that not all problems
> vectorize naturally. One example is
> 
>   ssd <- function(A,alpha) sum((Y - A*exp(-alpha*t))^2)
> 
> However, it should be worth noting that with the mapply() function at
> hand, it is pretty easy to turn a non-vectorized function into a
> vectorized one. 
> 
>   SSD <- function(A,alpha) mapply(ssd, A, alpha)
> 
> (Anybody want to try their hand on writing a general Vectorize()
> function? I.e. one that allowed
> 
>outer(Avec, alphavec, Vectorize(ssd))
> 
> to work.)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] [R] unvectorized option for outer()

[Tony Plate]

Duncan Murdoch wrote:
> On 10/31/2005 2:15 PM, Tony Plate wrote:
> 
>> [snipped comments irrelevant to this post]
>>
>> So, here's a first pass at a general Vectorize() function:
>>
>> Vectorize <- function(FUN, vectorize.args) {
>>  if (!all(is.element(vectorize.args, names(formals(FUN)
>>  stop("some args to vectorize are not args of FUN")
>>  FUNV <- eval(substitute(function(x, ...) mapply(FUN, x, 
>> MoreArgs=list(...)), list(FUN=FUN)))
>>  formals(FUNV) <- formals(FUNV)[c(rep(1, length(vectorize.args)), 2)]
>>  names(formals(FUNV))[seq(along=vectorize.args)] <- vectorize.args
>>  body(FUNV) <- body(FUNV)[c(1, 2, rep(3, length(vectorize.args)), 4)]
>>  body(FUNV)[seq(3,len=length(vectorize.args))] <- 
>> lapply(vectorize.args, as.name)
>>  FUNV
>> }
> 
> 
> I'd think the formals of the result should be identical to the formals 
> of the input.
> 
> Regarding the environment of the result:  it is used to determine the 
> meaning of symbols that aren't defined within the function, e.g. things 
> like "eval", "substitute", etc.  So I'd say that you don't want anything 
> special there, as long as you make sure that FUN is always evaluated in 
> its original environment.
> 
> Generally I don't like the look of that manipulation of the body of your 
> result; it looks pretty fragile to me.  But I haven't worked out exactly 
> what you're doing, or whether it's possible to avoid it.
> 
> Duncan Murdoch
> 

Thanks for explanation about the environment.

I should have said, that manipulation of the body creates the call
   mapply(FUN, A, alpha, MoreArgs=list(...))
from the original (x is a dummy argument)
   mapply(FUN, x, MoreArgs=list(...))

Are there better ways to create that call?  The difficulty is that the 
argument names in the call are derived from the actual arguments to 
Vectorize(), and there is an arbitrary number of them.

As for the formals of the result being identical to the formals of the 
input, I couldn't see any easy way to do that and still support optional 
arguments, e.g., if the input function formals were (a, b, t=1), then 
the result function would look something like:

function(a, b, t=1) mapply(FUN, a, b, t=t)

and missing(t) would not work correctly within FUN (with even more 
serious problems for optional arguments with no defaults).

-- Tony Plate


> 
>> ssd <- function(A,alpha,Y,t) sum((Y - A*exp(-alpha*t))2)
>> # SSD is a vectorized version of ssd
>> SSD <- function(Avec, alphavec, ...) mapply(ssd, Avec, alphavec, 
>> MoreArgs=list(...))
>> # Vectorize(ssd, c("A", "alpha")) should produce
>> # function(A, alpha, ...) mapply(ssd, A, alpha, MoreArgs=list(...))
>> Y <- 1:5; t <- 3
>> outer(1:3, 1:2, SSD, Y, t)
>> outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)
>>
>>  > # transcript of running the above commands
>>  > Vectorize(ssd, c("A", "alpha"))
>> function (A, alpha, ...)
>> mapply(function (A, alpha, Y, t)
>> sum((Y - A * exp(-alpha * t))^2), A, alpha, MoreArgs = list(...))
>> 
>>  > Y <- 1:5; t <- 3
>>  > outer(1:3, 1:2, SSD, Y, t)
>>   [,1] [,2]
>> [1,] 53.51878 54.92567
>> [2,] 52.06235 54.85140
>> [3,] 50.63071 54.77719
>>  > outer(1:3, 1:2, Vectorize(ssd, c("A", "alpha")), Y, t)
>>   [,1] [,2]
>> [1,] 53.51878 54.92567
>> [2,] 52.06235 54.85140
>> [3,] 50.63071 54.77719
>>  >
>>
>> [There are a couple of minor design issues around syntax -- what is 
>> the best way of specifying the arguments to vectorize? (e.g., what 
>> about an interface that allowed Vectorize(ssd ~ A * alpha)?), and 
>> should the function name rather than the definition appear in the 
>> result of Vectorize()?  But those are issues of secondary importance.]
>>
>> I have to confess I don't really understand how environments work with 
>> functions, so I don't know if this Vectorize() function will work in 
>> general.  What is the appropriate environment for returned value of 
>> Vectorize()?  Is this approach to creating a Vectorize() function on 
>> the right tack at all?  Any other improvements or fixes?
>>
>> -- Tony Plate
>>
>>
>> Peter Dalgaard wrote:
>>
>>> Thomas Lumley <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>> On Sun, 30 Oct 2005, Jonathan Rougier wrote:
>>>>
>>>>
>>>>> I'm not sure abo

Re: [Rd] x[1,], x[1,,], x[1,,,], ...

[Tony Plate]

Henrik Bengtsson wrote:
> Hi, thanks everyone.
> 
> Some comments below:
> 
> Peter Dalgaard wrote:
> 
>>Henrik Bengtsson <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>>Hi,
>>>
>>>is there a function in R already doing what I try to do below:
>>>
>>># Let 'x' be an array with *any* number of dimensions (>=1).
>>>x <- array(1:24, dim=c(2,2,3,2))
>>>...
>>>x <- array(1:24, dim=c(4,3,2))
>>>
>>>i <- 2:3
>>>
>>>ndim <- length(dim(x))
>>>if (ndim == 1)
>>>  y <- x[i]
>>>else if (ndim == 2)
>>>  y <- x[i,]
>>>else if (ndim == 3)
>>>  y <- x[i,,]
>>>else ...
>>>
>>>and so on.  My current solution is
>>>
>>>ndim <- length(dim(x))
>>>args <- rep(",", ndim)
>>>args[1] <- "i"
>>>args <- paste(args, collapse="")
>>>code <- paste("x[", args, "]", sep="")
>>>expr <- parse(text=code)
>>>y <- eval(expr)
>>>
>>>Is there another way I can do this in R that I have overlooked?
>>
>>
>>I think this should work:
>>
>>x <- array(1:24, dim=c(3,2,2,2)) # not c(2,2,3,2)
>>i <- 2:3
>>ndim <- length(dim(x))
>>ix <- as.list(rep(TRUE, ndim))
>>ix[[1]] <- i
>>do.call("[", c(list(x), ix))
> 
> 
> In my case, 'x' is huge, an I have to be careful with allocating memory. 
> Doesn't the 'list(x)' statement enforce an extra copy of 'x'?  Or will 
> lazy evaluation be able to pull out 'x' from the list again without 
> evaluating 'list(x)'?  I don't think so, but I'm not sure.  There is 
> also some overhead in 'ix[[1]] <- i', but 'i' is typically much smaller 
> than 'x' so this should be of minor importance.
> 
> What about Andy's suggestion
> 
>array(x[slice.index(x, 1) == 1], dim(x)[-1])?
> 
> There 'slice.index(x, 1)' will create an array of same size as 'x'.
> 
> I do not think the 'eval(parse(...))' has such overhead (correct me if 
> I'm wrong), but on the other hand, it is a more "ugly" solution. I 
> prefer not to use parse(), substitute() and friends in my code, if I 
> don't have to.
> 
> I just want to bring up this flavor of the problem too, because I often 
> find myself having to choose from similar options in other situations. 
> If you have further comments, I would appreciate those.
> 

Here's the type of manipulation I often do to approach these problems:

 > x <- array(1:24, dim=c(4,3,2))
 > i <- 2:3
 > x[i,,]
, , 1

  [,1] [,2] [,3]
[1,]26   10
[2,]37   11

, , 2

  [,1] [,2] [,3]
[1,]   14   18   22
[2,]   15   19   23

 > xic <- Quote(x[i,])
 > xic
x[i, ]
 > length(xic)
[1] 4
 > # now duplicate the empty index argument the appropriate number of times
 > xic <- xic[c(1:3,4,4)]
 > xic
x[i, , ]
 > eval(xic)
, , 1

  [,1] [,2] [,3]
[1,]26   10
[2,]37   11

, , 2

  [,1] [,2] [,3]
[1,]   14   18   22
[2,]   15   19   23

 >

I do this type of manipulation for precisely the reasons you bring up. 
I do know that in S-PLUS, using do.call() in the most obvious manner can 
result in unnecessary multiple duplications of data objects (as you 
suspect).  I don't think R is quite as bad, but I haven't done careful 
the experiments with R.

Do be careful though: this type of manipulation can expose a bug in R, 
which I don't think has been fixed (PR#7924).

-- Tony Plate

> Thanks
> 
> Henrik
> 
> __
> 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] typo in `eurodist'

[Tony Plate]

I would be wary of taking frequency of misspelling as an indication of 
"correctness".

Witness the following Google counts:

Amateur (correct): 52,300,000
Amature: 2,800,000
Amatuer: 2,660,000
Ameteur: 619,000
Ameture: 941,000
Ametuer: 574,000

Here's a common misspelling at > %10

Collectible (correct): 26,900,000
Collectable: 4,140,000

More targets at
http://www.yourdictionary.com/library/misspelled.html

(BTW, one can find a list of "commonly misspelt wods" using Google :-)

-- Tony Plate

(Ted Harding) wrote:
> On 08-Dec-05 Martin Maechler wrote:
> 
>>>>>>>"Torsten" == Torsten Hothorn <[EMAIL PROTECTED]>
>>>>>>>on Thu, 8 Dec 2005 08:51:57 +0100 (CET) writes:
>>
>>Torsten> On Wed, 7 Dec 2005, Prof Brian Ripley wrote:
>>>> I've often wondered about that.
>>Torsten> and the copy editor did too :-)
>>
>>>> I've presumed that the names were
>>>> deliberate, so have you checked the stated source?  It's not
>>>> readily available to me (as one would expect in Oxford)?
>>
>>Torsten> our library doesn't seems to have a copy of `The
>>Torsten> Cambridge Encyclopaedia', so I can't check
>>Torsten> either. Google has 74.900 hits for `Gibralta'
>>Torsten> (more than one would expect for a typo, I think)
>>Torsten> and 57.700.000 for `Gibraltar'.
>>
>>Torsten> So maybe both spellings are in use.
>>
>>Well,  do you expect web authors to have a much lower rate of
>>typos than 1:770 ?
>>My limited experience on "google voting for spelling correction"
>>has rather lowered my expectation on webauthors' education in
>>orthography...
>>
>>Martin
> 
> 
> Hmmm ... Using my Google's "Results ... of about xxx":
> 
> 
>   Gibraltar 50,700,000 
>   Gibralta  75,200
>   Gibraltr 573
>   Gibralar 836
>   Gibratar   1,020
>   Gibrltar 349
>   Gibaltar   1,850
>   Giraltar 530
>   Gbraltar 352
>   ibralter 576
> 
> I'm not proposing to get exhaustive about this, but a few further
> experiments suggest that other specific typos are typically O(500)
> in frequency:
> 
>   Gibralatar   589
>   Gibrlatar618
>   Gibrltar 349
>   Gobraltar652
> 
> 
> So -- if anyone can find a typo of "Gibraltar" which googles to
> more than 5000 hits (excepting "Gibralta")?
> 
> Best wishes,
> Ted.
> 
> 
> 
> E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
> Fax-to-email: +44 (0)870 094 0861
> Date: 08-Dec-05   Time: 18:58:04
> -- XFMail --
> 
> __
> 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] 0/1 vector for indexing leads to funny behaviour (PR#8389) (maybe a documentation deficiency?)

[Tony Plate]

Yes, 0/1 (numeric) are intended to be used as index vectors -- and they 
have the semantics of numeric indices, which is that 0 elements in the 
index are omitted from the result.  This can be a very useful mode of 
operation in many situations.

I was going to write "This is described in both the introduction to R, 
and in the documentation for '['", except that I checked before I wrote 
and was surprised to be unable to any discussion of zeros in indexing in 
any of the first three places I looked:

(1) help page for '[' (There is discussion of zero indices here, but 
only in the context of using matrices to index matrices, not in the 
context of ordinary vector indices).

(2) Section 2.7 "Index vectors: selecting and modifying subsets of a 
data set" in "An Introduction to R", which does say this about numeric 
indices:
 2. A vector of positive integral quantities. In
this case the values in the index vector must
lie in the set {1, 2, . . . , length(x)}
(This seems to commit the sin of not telling the whole truth.)

(3) Section 5.5 "Array Indexing.  Subsections of an array" (In "An 
Introduction to R")

Question for others: did I miss something obvious, or is this a 
documentation deficiency that zeros in indices are not discussed in 3 of 
some obvious first places to look?

If indeed this is a documentation deficiency, I'm happy to contribute 
documentation patch, but I await other opinions before spending any time 
on that.

-- Tony Plate

[EMAIL PROTECTED] wrote:
> Full_Name: Axel Rasche
> Version: 2.2.0
> OS: Linux
> Submission from: (NULL) (141.14.21.81)
> 
> 
> Dear Debuggers,
> 
> This is not a serious problem. Are 0/1 vectors intended to be used as index
> vectors? If yes, there is a bug. If not, it leads just to some funny behaviour
> rather than an error message.
> 
> In the appendix is some simple code to reproduce the problem. A logical vector
> as.logic(a) helps by indexing the vector b. The 0/1 vector a just returns the
> first value "a". But as many times as there is a 1 in a.
> 
> Best regards,
> Axel
> 
> 
> Appendix:
> 
> b = c("a","b","c","d")
> a = c(0,1,1,0)
> b[as.logical(a)]
> b[a]
> a = c(1,0,1,0)
> b[as.logical(a)]
> b[a]
> a = c(0,1,1,1)
> b[as.logical(a)]
> b[a]
> 
> __
> 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] 0/1 vector for indexing leads to funny behaviour (PR#8389) (maybe a documentation deficiency?)

[Tony Plate]

I appreciate the explanation that some details should not appear in the 
help pages or the Introduction to R manual.

However, I am puzzled by this part of Prof Ripley's response:

TP> [...] "An Introduction to R" [...] says this about
TP> numeric indices:
TP> 2. A vector of positive integral quantities. In
TP>this case the values in the index vector must
TP>lie in the set {1, 2, . . . , length(x)}
TP> (This seems to commit the sin of not telling the whole truth.)

BDR> No. Zero is not a positive integer.

That's what I was trying to say: the whole truth is that numeric index 
vectors that contain positive integral quantities can also contain 
zeros.  Upon rereading this passage yet again, I think it is more 
misleading than merely incomplete: the phrasings "positive integral 
quantities", and "*must* lie in the set ..." rule out the possibility of 
the vector containing zeros.

In this Section 2.7 in "An Introduction to R", the four types of index 
vectors are introduced with "Such index vectors can be any of four 
distinct types:". There is not even a hint that other types of index 
vectors can be used (e.g., positive integral quantities and zeros).  Is 
this really correct and helpful?  (The only way that I can see that this 
section can be interpreted as correct is to claim that that the phrasing 
"can be any of four distinct types" permits the existence of other types 
that are neither described nor hinted at.  However, this interpretation 
feels more clever than helpful.)

Tony Plate

Prof Brian Ripley wrote:
> ?"[" says
> 
> See Also:
> 
>  'list', 'array', 'matrix'.
> 
>  '[.data.frame' and '[.factor' for the behaviour when applied to
>  data.frame and factors.
> 
>  'Syntax' for operator precedence, and the _R Language_ reference
>  manual about indexing details.
> 
> and the `indexing details' are indeed where it says they are.
> 
> This is not an introductory topic, and it makes sense to have the 
> details in only one place and refer to it.  That help page is already 
> over-loaded.
> 
> 
> On Tue, 13 Dec 2005, Tony Plate wrote:
> 
>> Yes, 0/1 (numeric) are intended to be used as index vectors -- and they
>> have the semantics of numeric indices, which is that 0 elements in the
>> index are omitted from the result.  This can be a very useful mode of
>> operation in many situations.
>>
>> I was going to write "This is described in both the introduction to R,
>> and in the documentation for '['", except that I checked before I wrote
>> and was surprised to be unable to any discussion of zeros in indexing in
>> any of the first three places I looked:
>>
>> (1) help page for '[' (There is discussion of zero indices here, but
>> only in the context of using matrices to index matrices, not in the
>> context of ordinary vector indices).
>>
>> (2) Section 2.7 "Index vectors: selecting and modifying subsets of a
>> data set" in "An Introduction to R", which does say this about numeric
>> indices:
>> 2. A vector of positive integral quantities. In
>>this case the values in the index vector must
>>lie in the set {1, 2, . . . , length(x)}
>> (This seems to commit the sin of not telling the whole truth.)
> 
> 
> No. Zero is not a positive integer.
> 
>> (3) Section 5.5 "Array Indexing.  Subsections of an array" (In "An
>> Introduction to R")
>>
>> Question for others: did I miss something obvious, or is this a
>> documentation deficiency that zeros in indices are not discussed in 3 of
>> some obvious first places to look?
>>
>> If indeed this is a documentation deficiency, I'm happy to contribute
>> documentation patch, but I await other opinions before spending any time
>> on that.
>>
>> -- Tony Plate
>>
>> [EMAIL PROTECTED] wrote:
>>
>>> Full_Name: Axel Rasche
>>> Version: 2.2.0
>>> OS: Linux
>>> Submission from: (NULL) (141.14.21.81)
>>>
>>>
>>> Dear Debuggers,
>>>
>>> This is not a serious problem. Are 0/1 vectors intended to be used as 
>>> index
>>> vectors? If yes, there is a bug. If not, it leads just to some funny 
>>> behaviour
>>> rather than an error message.
>>>
>>> In the appendix is some simple code to reproduce the problem. A 
>>> logical vector
>>> as.logic(a) helps by indexing the vector b. The 0/1 vector a just 
>>> returns the
>>> fir

Re: [Rd] prod(numeric(0)) surprise

[Tony Plate]

Since the virtue and reliability of Wikis was brought up, I created a R 
Wiki page for this at 
http://www.sciviews.org/_rgui/wiki/doku.php?id=beginners:surprises:emptysetfuncs
:-)

Anyone: please correct errors and improve it!

Tony Plate

Duncan Murdoch wrote:
> On 1/9/2006 1:27 PM, Liaw, Andy wrote:
> 
>>If you haven't seen this in your math courses, perhaps this would help:
>>
>>http://en.wikipedia.org/wiki/Empty_set
>>
> 
> 
> This is what is so great about Wikipedia:  it gives certainty where I'd 
> only call it a fairly standard convention.  ;-)
> 
> Duncan Murdoch
> 
> 
> 
>>which says, in part:
>>
>>Operations on the empty set
>>
>>Operations performed on the empty set (as a set of things to be operated
>>upon) can also be confusing. (Such operations are nullary operations.) For
>>example, the sum of the elements of the empty set is zero, but the product
>>of the elements of the empty set is one (see empty product). This may seem
>>odd, since there are no elements of the empty set, so how could it matter
>>whether they are added or multiplied (since "they" do not exist)?
>>Ultimately, the results of these operations say more about the operation in
>>question than about the empty set. For instance, notice that zero is the
>>identity element for addition, and one is the identity element for
>>multiplication.
>>
>>
>>Andy
>>
>>
>>From: Martin Morgan
>>
>>>I guess I have to say yes, I'd exepct
>>>
>>>x <- 1:10
>>>sum(x[x>10]) ==> numeric(0)
>>>
>>>this would be reinforced by recongnizing that numeric(0) is not zero,
>>>but nothing. I guess the summation over an empty set is an empty set,
>>>rather than a set containing the number 0. Certainly these
>>>
>>>exp(x[x>10]) ==> numeric(0)
>>>numeric(0) + 1 ==> numeric(0)
>>>
>>>would give me pause.
>>>
>>>
>>>Gabor Grothendieck <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>>The way to think about it is:
>>>>
>>>>   prod(rep(x,n)) == x^n
>>>>
>>>>and that works for n=0 too.
>>>
>>>Hmm, Not sure what to put in for x and n? do you mean x == numeric(0),
>>>n == 0 (0 copies of an empty set), x == ANY n == numeric(0) (an empty
>>>set of ANYthing), x == numeric(0), n == numeric(0) ? For all of these,
>>>x^n evaluates to numeric(0).
>>>
>>>Martin (Morgan)
>>>
>>>Duncan Murdoch <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>>On 1/9/2006 12:40 PM, Martin Morgan wrote:
>>>>
>>>>>I'm a little confused. I understand that numeric(0) means an empty
>>>>>numeric vector, not the number 0 expressed as numeric. As 
>>>
>>>it is now,
>>>
>>>>>prod(numeric(0)) generates something -- a vector of length 1
>>>>>containing the number 1 -- from nothing. I would have expected
>>>>>prod(numeric(0)) ==> numeric(0)
>>>>>this is consistent with
>>>>>numeric(0) ==> numeric(0)
>>>>>numeric(0) * 1 ==> numeric(0)
>>>>>cumprod(numeric(0)) ==> numeric(0)
>>>>>and, because concatenation occus before function evaluation,
>>>>>prod(c(numeric(0),1)) ==> prod( c(1) ) ==> 1
>>>>>I would expect sum() to behave the same way, e.g., sum(numeric(0))
>>>>>==>
>>>>>numeric(0). From below,
>>>>>
>>>>
>>>>I think the code below works as I'd expect.  Would you 
>>>
>>>really like the
>>>
>>>>last answer to be numeric(0)?
>>>>
>>>> > x <- 1:10
>>>> > sum(x)
>>>>[1] 55
>>>> > sum(x[x>5])
>>>>[1] 40
>>>> > sum(x[x>10])
>>>>[1] 0
>>>>
>>>>Duncan Murdoch
>>>>
>>>>
>>>>>>>>>> consider exp(sum(log(numeric(0 ... ?)
>>>>>>>> >> That's a fairly standard mathematical convention,
>>>>>>which
>>>>>>>> is presumably why sum and prod work that way.
>>>>>>>> >> Duncan Murdoch
>>>>>
>>>>>I would have expected numeric(0) as the result (numeric(0) is the
>>>>>result from log(numeric(0)), etc).
>>>>>Martin (Morgan)
>>>>>Martin Maech

Re: [Rd] Wikis (was about prod(numeric(0)))

[Tony Plate]

I agree with everything you say about the structure and organization of 
the Wiki (needs top-level R-related structure, the 
Wiki-administration/editing stuff dominates, etc.)  But, it's also 
possible to spend so much time talking about how to do it, that it never 
gets done...

Still, it really does look like it would be worth putting some effort 
into the top level structure early on, because from the material I saw 
about maintaining the wiki, it looks like a bit of a chore to impose a 
new top-level structure (requires scripts, admittedly simple, that 
rename files and change links within files -- so, presumably, can only 
be done by the Wiki administrator.)

Also, I had a little difficulty figuring out exactly how to create new 
pages, and my attempts were not clean -- I seemed to have left two items 
with the same name at the same level in the index.

Everything is an experiment!

Maybe when Phillippe Grosjean returns to his work he can put some more 
R-related top-level structure on his wiki?

In the meantime, anyone else can go in there and start proposing some 
structure...

-- Tony Plate

PS. Detlef Steuer did say that he would be happy to shut down his wiki 
and let the sciviews one be "the" R Wiki.  I had previously put some 
material on Detlef's Wiki, but this time on put it on the sciviews Wiki.

Ben Bolker wrote:
> Tony Plate  acm.org> writes:
> 
>  >
>  > Since the virtue and reliability of Wikis was brought up, I created a R
>  > Wiki page for this at
>  > 
> http://www.sciviews.org/_rgui/wiki/doku.php?id=beginners:surprises:emptysetfuncs
>  >
>  >
>  > Anyone: please correct errors and improve it!
>  >
>  > Tony Plate
>  >
> 
>OK, now I have another question:
> I see a wiki at
> http://fawn.unibw-hamburg.de/cgi-bin/Rwiki.pl?RwikiHome
> administered by Detlef Steuer
>I see another at http://www.sciviews.org/_rgui/wiki/doku.php
> (Phillippe Grosjean)
> which is nominally geared toward beginners/GUI interfaces.
> 
>   I'm not saying I could do any better, but both of these look
> as though they'd be pretty hard to get into if you were really
> a beginner or intermediate R user looking for info ... Paul
> John's Rtips (http://www.ku.edu/~pauljohn/R/Rtips.html) is actually
> about the best example about there -- the flat hierarchy might not
> work too well for a really big wiki, but having at least
> a good first-level hierarchy set up (and making sure that
> what new users see is not a lot of detail about how to extend
> the wiki) seems really important.
> 
>Sorry to criticize, but I am happy to start working
> on populating a wiki -- but only if the structure is there
> so that I can figure out where to put stuff and hope that
> someone who needs it will ever be able to find it ...
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Large discrepancies in the same object being saved to .RData

[Tony Plate]

Another way of seeing the environments referenced in an object is using 
str(), e.g.:


> f1 <- function() {
+ junk <- rnorm(1000)
+ x <- 1:3
+ y <- rnorm(3)
+ lm(y ~ x)
+ }
> v1 <- f1()
> object.size(f1)
1636 bytes
> grep("Environment", capture.output(str(v1)), value=TRUE)
[1] "  .. ..- attr(*, \".Environment\")= "
[2] "  .. .. ..- attr(*, \".Environment\")= "
>

-- Tony Plate

On 7/10/2010 10:10 PM, bill.venab...@csiro.au wrote:

Well, I have answered one of my questions below.  The hidden
environment is attached to the 'terms' component of v1.

To see this

   

lapply(v1, environment)
 

$coefficients
NULL

$residuals
NULL

$effects
NULL

$rank
NULL

$fitted.values
NULL

$assign
NULL

$qr
NULL

$df.residual
NULL

$xlevels
NULL

$call
NULL

$terms


$model
NULL

   

rm(junk, envir = with(v1, environment(terms)))
usedVcells()
 

[1] 96532
   


 

This is still a bit of a trap for young (and old!) players...

I think the main point in my mind is why is it that object.size()
excludes enclosing environments in its reckonings?

Bill Venables.

-Original Message-
From: Venables, Bill (CMIS, Cleveland)
Sent: Sunday, 11 July 2010 11:40 AM
To: 'Duncan Murdoch'; 'Paul Johnson'
Cc: 'r-devel@r-project.org'; Taylor, Julian (CMIS, Waite Campus)
Subject: RE: [Rd] Large discrepancies in the same object being saved to .RData

I'm still a bit puzzled by the original question.  I don't think it
has much to do with .RData files and their sizes.  For me the puzzle
comes much earlier.  Here is an example of what I mean using a little
session

   

usedVcells<- function() gc()["Vcells", "used"]
usedVcells()### the base load
 

[1] 96345

### Now look at what happens when a function returns a formula as the
### value, with a big item floating around in the function closure:

   

f0<- function() {
 

+ junk<- rnorm(1000)
+ y ~ x
+ }
   

v0<- f0()
usedVcells()   ### much bigger than base, why?
 

[1] 10096355
   

v0 ### no obvious envirnoment
 

y ~ x
   

object.size(v0)  ### so far, no clue given where
 

### the extra Vcells are located.
372 bytes

### Does v0 have an enclosing environment?

   

environment(v0) ### yep.
 


   

ls(envir = environment(v0)) ### as expected, there's the junk
 

[1] "junk"
   

rm(junk, envir = environment(v0))  ### this does the trick.
usedVcells()
 

[1] 96355

### Now consider a second example where the object
### is not a formula, but contains one.

   

f1<- function() {
 

+ junk<- rnorm(1000)
+ x<- 1:3
+ y<- rnorm(3)
+ lm(y ~ x)
+ }

   

v1<- f1()
usedVcells()  ### as might have been expected.
 

[1] 10096455

### in this case, though, there is no
### (obvious) enclosing environment

   

environment(v1)
 

NULL
   

object.size(v1)  ### so where are the junk Vcells located?
 

7744 bytes
   

ls(envir = environment(v1))  ### clearly wil not work
 

Error in ls(envir = environment(v1)) : invalid 'envir' argument

   

rm(v1) ### removing the object does clear out the junk.
usedVcells()
 

[1] 96366
   
 

And in this second case, as noted by Julian Taylor, if you save() the
object the .RData file is also huge.  There is an environment attached
to the object somewhere, but it appears to be occluded and entirely
inaccessible.  (I have poked around the object components trying to
find the thing but without success.)

Have I missed something?

Bill Venables.

-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On 
Behalf Of Duncan Murdoch
Sent: Sunday, 11 July 2010 10:36 AM
To: Paul Johnson
Cc: r-devel@r-project.org
Subject: Re: [Rd] Large discrepancies in the same object being saved to .RData

On 10/07/2010 2:33 PM, Paul Johnson wrote:
   

On Wed, Jul 7, 2010 at 7:12 AM, Duncan Murdoch  wrote:

 

On 06/07/2010 9:04 PM, julian.tay...@csiro.au wrote:

   

Hi developers,



After some investigation I have found there can be large discrepancies in
the same object being saved as an external "xx.RData" file. The immediate
repercussion of this is the possible increased size of your .RData workspace
for no apparent reason.




 

I haven't worked through your example, but in general the way that local
objects get captured is when part of the return value includes an
environment.

   

Hi, can I ask a follow up question?

Is there a tool to browse *.Rdata files without loading them into R?

 

I don't know of one.  You can load the whole file into an empty
environment, but then you lose information about "where did it come from"?

Duncan Murdoch
   

In HDF5 (a data storage format we use sometimes), there is a CLI
program "h5dump" th

Re: [Rd] Drop single-dimensional array

[Tony Plate]

 On 9/9/2010 10:54 AM, William Dunlap wrote:

-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Arni Magnusson
Sent: Wednesday, September 08, 2010 11:55 AM
To: r-devel@r-project.org
Cc: Simon Urbanek
Subject: [Rd] Drop single-dimensional array

Hi Simon, thank you for the concise reply.

Do you mean the reported behavior of drop() is not a bug?

It looks like a borderline bug to me (see below), but I'm not
the judge of
that. If this is the intended behavior and serves an actual
purpose, then
that could be explicitly documented in a \note{} on the help page.

Such a note would slightly reduce the surprise of users
running into this
behavior.

This is related to the oddity that one-dimensional arrays are:

array(month.abb, dim=c(1,1,12))  # array
array(month.abb, dim=c(1,12))# matrix
array(month.abb, dim=12) # array

Firstly, one would expect the pattern to be
array-matrix-vector.

I would expect the array() constructor function to return
something of class array.  (I guess matrix is acceptable
because it inherits from array).

One dimensional arrays and vectors act very similarly
when used in R code.  E.g., names(array1d) gives you
the same thing as dimnames(array1d)[[1]].  Accessing
them from C code probably shows more differences.
Are there features beyond drop's behavior that are
causing you to be concerned about differences between
the 2 types?

drop(x) and x[..., drop=TRUE] have always bugged me
because you couldn't control which dimensions got
dropped.  E.g., if you have a n by 2 by 3 array
and want to get the 3rd n by 2 slice of it as a matrix
you can do
array[,,3,drop=TRUE]
except when n==1.  It would be nice to be able to say
"drop the 3rd dimension, throwing an error if that
dimension is not 1".

That always bugged me too.  The 'abind' package has an 'adrop()' function with 
this behavior, and I was just working on an enhancement of it that would make 
it able to convert 1-d arrays to named vectors when this thread started.

-- Tony Plate


Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Bug in read.table?

[Tony Plate]

The problem has to do with the quote characters in the data (R is probably 
interpreting the 'minutes' and 'seconds' as delimiter characters).

With a smaller data file, I can reproduce the strange behavior.

read.table() can read the data correctly if given quote="" to disable the 
interpretation of quote chars.

Contents of tmp2.txt:
 37.8275120694  -1.2077972583 001º12'28.07013"W 037º49'39.04345"N
 37.8275121083  -1.2077974806 001º12'28.07093"W 037º49'39.04359"N
 37.8275118539  -1.2077974338 001º12'28.07076"W 037º49'39.04267"N
 37.8275119923  -1.2077974626 001º12'28.07087"W 037º49'39.04317"N


> read.table(file.path("tmp2.txt"), header=FALSE, as.is=TRUE)
V1V2V3V4
1 37.82751 -1.207797 001º12'28.07076"W 037º49'39.04267"N
2 37.82751 -1.207797 001º12'28.07087"W 037º49'39.04317"N
3 37.82751 -1.207797 001º12'28.07013"W 037º49'39.04345"N
4 37.82751 -1.207797 001º12'28.07093"W 037º49'39.04359"N
5 37.82751 -1.207797 001º12'28.07076"W 037º49'39.04267"N
6 37.82751 -1.207797 001º12'28.07087"W 037º49'39.04317"N
Warning message:
In read.table(file.path("tmp2.txt"), header = FALSE, as.is = TRUE) :
  incomplete final line found by readTableHeader on 'tmp2.txt'
> read.table(file.path("tmp2.txt"), header=FALSE, as.is=TRUE, quote="")
V1V2V3V4
1 37.82751 -1.207797 001º12'28.07013"W 037º49'39.04345"N
2 37.82751 -1.207797 001º12'28.07093"W 037º49'39.04359"N
3 37.82751 -1.207797 001º12'28.07076"W 037º49'39.04267"N
4 37.82751 -1.207797 001º12'28.07087"W 037º49'39.04317"N
>

The docs for read.table() direct the reader to the docs for scan() regarding 
the behavior with embedded quote chars.  The behavior of read.table() on this 
data with the default quote chars is puzzling though.

-- Tony Plate

On 11/5/2010 5:22 PM, jgar...@ija.csic.es wrote:

Hi,

I'm writting to this list as I'm puzzled about the behaviour of
read.table(). It is hard to believe that there is a bug in this utils'
function, but for my:

R version 2.12.0 alpha (2010-09-28 r53056)

I'm using scan and read.table to read a number of files, which are as:

---

Project: Murta Sonda
Program: GrafNav Version 8.30.1007
Profile: javier
Source:  GPS Epochs(Combined)
ProcessInfo: Run (1) by Unknown on 11/04/2010 at 19:05:17

Datum:   WGS84, (processing datum)
Master 1:Name LaMurta, Status ENABLED
  Antenna height 2.066 m, to L1-PC (NOV702GG, MeasDist 1.980 m
to mark/ARP)
  Position 37 49 38.15069, -1 12 27.55445, 368.197 m (WGS84,
Ellipsoidal hgt)
Remote:  Antenna height 1.781 m, to L1-PC (NOV702GG, MeasDist 1.695 m
to mark/ARP)
UTC Offset:  15 s
Local time:  +2.0 h, CEST [Central European Savings Time]
Geoid:   EGM2008-World.wpg (Absolute correction)

   Latitude  Longitude LonTextLoTextLongitudTextL
LatTextLaTextLatitudeTextLH-EllH-MSL LocalUTCDa
LocalUTC
  (Deg)  (Deg) (DeMi   (Sec)  (DeMi   (Sec)   (m)
(m)  (DMY)   (HMS)
  37.8275120694  -1.2077972583 001º12'28.07013"W 037º49'39.04345"N
368.998  318.059 25/10/201016:59:00
  37.8275121083  -1.2077974806 001º12'28.07093"W 037º49'39.04359"N
368.994  318.055 25/10/201016:59:15
  37.8275118539  -1.2077974338 001º12'28.07076"W 037º49'39.04267"N
368.997  318.058 25/10/201016:59:30
  37.8275119923  -1.2077974626 001º12'28.07087"W 037º49'39.04317"N
368.998  318.060 25/10/201016:59:45
  37.8275323099  -1.2078075891 001º12'28.10732"W 037º49'39.11632"N
368.869  317.930 25/10/201017:00:00
  37.8275323374  -1.2078077002 001º12'28.10772"W 037º49'39.11641"N
368.866  317.927 25/10/201017:00:15
  37.8275325076  -1.2078075314 001º12'28.10711"W 037º49'39.11703"N
368.859  317.920 25/10/201017:00:30
  37.8275325306  -1.2078075056 001º12'28.10702"W 037º49'39.11711"N
368.861  317.922 25/10/201017:00:45
  37.8275323639  -1.2078075917 001º12'28.10733"W 037º49'39.11651"N
368.853  317.914 25/10/201017:01:00
  37.8275326222  -1.2078076861 001º12'28.10767"W 037º49'39.11744"N
368.857  317.918 25/10/201017:01:15
---

with a number of different records for each file.

To read the data I'm using:

---
  dat.names<- scan(file.path("path_and_filename"),
what="character",
skip = 16, nlines=1)
  if(length(dat.names) 

Re: [Rd] RFC: sapply() limitation from vector to matrix, but not further

[Tony Plate]

The abind() function from the abind package is an alternative here -- it can 
take a list argument, which makes it easy to use with the result of lapply().  
It's also able take direction about which dimension to join on.

> x <- list(a=1,b=2,c=3)
> f <- function(v) matrix(v, nrow=2, ncol=4)
> sapply(x, f)
 a b c
[1,] 1 2 3
[2,] 1 2 3
[3,] 1 2 3
[4,] 1 2 3
[5,] 1 2 3
[6,] 1 2 3
[7,] 1 2 3
[8,] 1 2 3
>
> # The 'along=' argument to abind() determines on which dimension
> # the list elements are joined.  Use a fractional value to put the new
> # dimension between existing ones.
>
> dim(abind(lapply(x, f), along=0))
[1] 3 2 4
> dim(abind(lapply(x, f), along=1.5))
[1] 2 3 4
> dim(abind(lapply(x, f), along=3))
[1] 2 4 3
> abind(lapply(x, f), along=3)
, , a

 [,1] [,2] [,3] [,4]
[1,]1111
[2,]1111

, , b

 [,1] [,2] [,3] [,4]
[1,]2222
[2,]2222

, , c

 [,1] [,2] [,3] [,4]
[1,]3333
[2,]3333

>

On 12/28/2010 8:49 AM, Martin Maechler wrote:

Gabor Grothendieck
 on Mon, 27 Dec 2010 17:06:25 -0500 writes:

 >  On Wed, Dec 1, 2010 at 3:39 AM, Martin Maechler
 >wrote:
 >>  My proposal -- implemented and "make check" tested -- is
 >>  to add an optional argument  'ARRAY' which allows
 >>
 >>>  sapply(v, myF, y = 2*(1:5), ARRAY=TRUE)

 >  It would reduce the proliferation of arguments if the
 >  simplify= argument were extended to allow this,
 >  e.g. simplify = "array" or perhaps simplify = n would
 >  allow a maximum of n dimensions.

That's a good idea, though it makes the
implementation/documentation very slightly more complicated.

I'm interested to get more feedback on my other questions,
notably the only about *changing*  vapply() (on the C-level) to
behave "logical" in the sense of adding one  dim(.)ension in
those cases, the FUN.VALUE (result prototype) has a dim().


Martin

__
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] feature request: additional hook in plot.new()

[Tony Plate]

Request: An additional hook in plot.new() that is called prior to the call to 
.Internal(plot.new()).
Reason: To allow the hook to set up or modify a graphics device that the new 
plot will appear in.

The code change needed for this is simple - just 4 new lines of R code in 
src/library/graphics/R/plot.R:plot.new()

Current definition of plot.new() in src/library/graphics/R/plot.R:

plot.new <- function()
{
.Internal(plot.new())
for(fun in getHook("plot.new")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
invisible()
}

New definition of plot.new() in src/library/graphics/R/plot.R:

plot.new <- function()
{
for(fun in getHook("plot.prenew")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
.Internal(plot.new())
for(fun in getHook("plot.new")) {
if(is.character(fun)) fun <- get(fun)
try(fun())
}
invisible()
}

In src/library/graphics/man/frame.Rd after the existing sentence beginning "There is 
a hook..." in the DETAILS section, the following sentence could be added:

"There is another hook called \code{"plot.prenew"} which is called before advancing 
the frame.  This hook can be used to create a new plot "

The name of the hook is not very important -- I've suggested "plot.prenew" here.  Another 
possibility could be "plot.new0".

More detail on the reason:

In a tabbed graphics widget 
(https://r-forge.r-project.org/projects/tabbedplots/ ), having this hook would 
enable it to operate in a mode where a new tab is automatically created for 
each new plot.

thanks for your consideration,

Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Require of gWidgetsRGtk2 fails: RGtk2.dll can't be found, but it's there

[Tony Plate]

I also had frustrations trying to use libary RGtk2 under Windows XP.

I kept getting the message
   "unable to load shared object C:\R\site-library\RGtk2\libs\i386\RGtk2.dll"
even though it was on my path.

Uninstalling and reinstalling various versions of GTK2, both through R
and outside R, many times, including rebooting Windows, did not help.

With the help of some comments on R-help (Neil Rice, Mar 7, 2011), I found that
there was another conflicting version of zlib1.dll in a directory on my PATH.
Removing that directory from the path (inside R) fixed the problem and I am able
to run RGtk2 now.

Here's an R expression to look for copies of the various DLLs that GTK2 uses 
(change "c:/GTK2-Runtime/bin/" to be appropriate for your system):

 > for (dll in list.files("c:/GTK2-Runtime/bin/", pattern="*.dll$")) 
 > print(with(list(x=file.path(strsplit(Sys.getenv("PATH"), ";")[[1]], dll)), 
 > x[file.exists(x)]))
[1] "C:\\GTK2-Runtime\\bin/freetype6.dll"
[1] "C:\\GTK2-Runtime\\bin/intl.dll"
[1] "C:\\GTK2-Runtime\\bin/libatk-1.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libcairo-2.dll"
[1] "C:\\GTK2-Runtime\\bin/libcairo-gobject-2.dll"
[1] "C:\\GTK2-Runtime\\bin/libcairo-script-interpreter-2.dll"
[1] "C:\\GTK2-Runtime\\bin/libexpat-1.dll"
[1] "C:\\GTK2-Runtime\\bin/libfontconfig-1.dll"
[1] "C:\\GTK2-Runtime\\bin/libgailutil-18.dll"
[1] "C:\\GTK2-Runtime\\bin/libgdk-win32-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgdk_pixbuf-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgio-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libglib-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgmodule-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgobject-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgthread-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libgtk-win32-2.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libpango-1.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libpangocairo-1.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libpangoft2-1.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libpangowin32-1.0-0.dll"
[1] "C:\\GTK2-Runtime\\bin/libpng14-14.dll"
[1] "C:\\GTK2-Runtime\\bin/zlib1.dll"
 >

If there are any lines beginning with [2] in the output, there are multiple
versions of DLLs and these are potential problems (check that either the
DLLs are the same version, or that the GTK2 version is ahead on the path).

Note that is is not sufficient that the GTK2 library is on the path -- it has
to be ahead of other path components that have conflicting DLLs.


On 6/11/2011 8:59 PM, Michael Lawrence wrote:
> I'm working on a mechanism that will download GTK+ (the official zip files)
> into a predetermined location and put that location in front of the other
> paths at load time.  Hopefully this will resolve these continuing issues.
>
> Michael
>
> On Fri, Jun 10, 2011 at 6:07 AM, Janko Thyson<
> janko.thyson.rst...@googlemail.com>  wrote:
>
>> Okay, at least some positive result today (language issue ;-))
>>
>> Thanks for trying. Seems like GTK2 and me are not meant to be ...
>>
>> Regards,
>> Janko
>>
>>
>> On 10.06.2011 14:36, Prof Brian Ripley wrote:
>>
>>> It is a Microsoft error message, so your Windows is translating it, not R.
>>>   It does say 'The specified module' in English Windows, without saying who
>>> specified the module (but it does often produce a popup naming the module).
>>>
>>> I've no better idea what your problem is: the @ReadMe instructions work
>>> for me, Uwe on winbuilder and in our teaching lab (and the advice in RGtk2
>>> does not).
>>>
>>> On Fri, 10 Jun 2011, Janko Thyson wrote:
>>>
>>>   On 10.06.2011 13:18, Prof Brian Ripley wrote:
   On Fri, 10 Jun 2011, Janko Thyson wrote:

 Dear list,

 I've been trying to get gWidgets/gWidgetsRGtk2 to run
 every other month for a while, but somehow I simply can't
 figure out what's going wrong.


   Your subject line indicates your confusion.  It does not say
   RGtk2.dll cannot be found (at least, the English version of the
   message does not say so).

   What it means is that RGtk2.dll or one of the DLLs it depends on
   cannot be found.  See the instructions at
   http://cran.r-project.org/bin/windows/contrib/2.13/@ReadMe

   It is Microsoft's error message, not ours.


 Thanks for your answer. I followed the advice in the readme file and
 installed


 http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.22/gtk+-bundle_2.22.0-201010
 16_win32.zip
 Previously I made sure that all other previously installed GTK+ runtime
 environments were removed and that the windows PATH reflects the correct
 path to
 the "new" GTK+ files. I also made sure I started a new R session before
 trying
 'require(gWidgetsRGtk2)' again. Yet, the same error. More precisely, a
 dialog box
 pops up asking me to install GTK+ or not. That's what's confusing me as
 well: the
 package's recommendation with respect to the version of an GTK+ runtime
 envi

[Rd] Why is the 64bit Windows version of package RSVGTipsDevice not available on CRAN?

[Tony Plate]

On CRAN, the package RSVGTipsDevice is only installed for 32bit Windows, and is 
not available as a 64bit package for Windows.

The file linked to in the package check summary on CRAN says "NB: this package 
is only installed for sub-architecture 'i386' ".

What do I need to do to make it available as both 64bit and 32bit on CRAN? (I 
am the maintainer of the package).

It builds, checks and runs fine as a 64 bit package on my own Windows 64 bit 
(XP) machine.

Has a flag has been set somewhere because some time in the past this package 
had problems running in 64 bit mode?

Here's the truncated output from the link from CRAN package check page:

http://www.r-project.org/nosvn/R.check/r-release-windows-ix86+x86_64/RSVGTipsDevice-00check.html

  * using R version 2.14.0 (2011-10-31)
  * using platform: i386-pc-mingw32 (32-bit)
  * using session charset: ISO8859-1
  * checking for file 'RSVGTipsDevice/DESCRIPTION' ... OK
  * this is package 'RSVGTipsDevice' version '1.0-4'
  * checking package namespace information ... OK
  * checking package dependencies ... OK
  * checking if this is a source package ... OK
  * checking if there is a namespace ... OK
  * checking whether package 'RSVGTipsDevice' can be installed ... OK
  * checking installed package size ... OK
NB: this package is only installed for sub-architecture 'i386'
  * checking package directory ... OK
  * checking for portable file names ... OK
  * ... [truncated]


Here's the output of R CMD check on my own machine:

$ /cygdrive/c/R/R-2.14.0/bin/x64/R.exe CMD check RSVGTipsDevice_1.0-4.tar.gz
* using log directory 'D:/tplate/R/rforge/rsvgtipsdevice/RSVGTipsDevice.Rcheck'
* using R version 2.14.0 (2011-10-31)
* using platform: x86_64-pc-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'RSVGTipsDevice/DESCRIPTION' ... OK
* this is package 'RSVGTipsDevice' version '1.0-4'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking whether package 'RSVGTipsDevice' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* loading checks for arch 'i386'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
* loading checks for arch 'x64'
** checking whether the package can be loaded ... OK
** checking whether the package can be loaded with stated dependencies ... OK
** checking whether the package can be unloaded cleanly ... OK
** checking whether the namespace can be loaded with stated dependencies ... OK
** checking whether the namespace can be unloaded cleanly ... OK
* checking for unstated dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking line endings in C/C++/Fortran sources/headers ... OK
* checking line endings in Makefiles ... OK
* checking for portable use of $(BLAS_LIBS) and $(LAPACK_LIBS) ... OK
* checking compiled code ... OK
* checking examples ...
** running examples for arch 'i386' ... OK
** running examples for arch 'x64' ... OK
* checking PDF version of manual ... OK


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] should Sys.glob() cope with a UNC windows path beginning with backslashes?

[Tony Plate]

I find that Sys.glob() doesn't like UNC paths where the initial slashes are backslashes.  
The help page for Sys.glob() doesn't specificly mention UNC paths, but does say: 
"File paths in Windows are interpreted with separator \ or /."  Is the failure 
to treat a path beginning with a double-backslash as a UNC network drive path the 
intended behavior?

E.g., on a Windows system where \\foo is a network drive and \\foo\bar exists, 
I see:


Sys.glob("//foo/bar")

[1] "//foo/bar"

Sys.glob("//foo\\bar")

[1] "//foo\\bar"

Sys.glob("foo/bar")

character(0)

Sys.glob("foo\\bar")


(the pattern of behavior seems to be that initial backslashes are not 
equivalent to forward slashes, but later backslashes are.)

This is not a big deal, but I noticed it because it results in Rcmd check giving a 
spurious warning when started from a cygwin shell with a working directory that is a 
network drive specified as a UNC path.  This happens because mandir in 
tools:::.writePkgIndices has the form \\foo/bar/R/packages/mypkg/man, which results in 
the false warning "there is a 'man' dir but no help pages in this package."  A 
simple workaround was to use a drive-letter mount for the network drive.


sessionInfo()
R version 2.9.1 (2009-06-26) 
i386-pc-mingw32 


locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base 




-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] should Sys.glob() cope with a UNC windows path beginning with backslashes?

[Tony Plate]

Prof Brian Ripley wrote:

On Fri, 26 Jun 2009, Tony Plate wrote:

I find that Sys.glob() doesn't like UNC paths where the initial 
slashes are backslashes.  The help page for Sys.glob() doesn't 
specificly mention UNC paths, but does say: "File paths in Windows 
are interpreted with separator \ or /."  Is the failure to treat a 
path beginning with a double-backslash as a UNC network drive path 
the intended behavior?


Yes.  There are general warnings about non-POSIX Windows paths in 
several of the help files.


The following comments should alert you to possible restrictions:

  The \code{glob} system call is not part of Windows, and we supply an
  emulation.

  File paths in Windows are interpreted with separator \code{\\} or
  \code{/}.  Paths with a drive but relative (such as \code{c:foo\\bar})
  are tricky, but an attempt is made to handle them correctly.

If you want to submit a well-tested patch, it will be considered.
The problem seems to be in the function dos_wglob() in 
src/gnuwin32/dos_wglob.c.  This function treats backslashes as a escape 
characters when they precede one of the metacharacters []-{}~\.  So, an 
initial double backslash is changed to an initial single backslash. 
Consequently, the existing code does see network drives when the prefix 
is 3 or 4 backslashes.


Here's a patch that adds special treatment for a prefix of exactly two 
backslashes so that Sys.glob() sees a network drive in this case:


/cygdrive/c/Rbuild/R-2.9.1/src/gnuwin32
$ diff -c dos_wglob.c~ dos_wglob.c
*** dos_wglob.c~Sun Sep 21 16:05:28 2008
--- dos_wglob.c Mon Jun 29 12:09:47 2009
***
*** 203,208 
--- 203,222 
   *bufnext++ = BG_SEP;
   patnext += 2;
 }
+ /* Hack to treat UNC network drive specification correctly:
+  * Without this code, '\\' (i.e., literally two backslashes in 
pattern)

+  * at the beginning of a path is not recognized as a network drive,
+  * because the GLOB_QUOTE loop below changes the two backslashes 
to one.

+  * So, in the case where there are two but not three backslashes at
+  * the beginning of the path, transfer these to the output.
+  */
+ if (patnext == pattern && bufend - bufnext > 2 &&
+   pattern[0] == BG_SEP2 && pattern[1] == BG_SEP2 &&
+   pattern[2] != BG_SEP2) {
+   *bufnext++ = pattern[0];
+   *bufnext++ = pattern[1];
+   patnext += 2;
+ }
 #endif

 if (flags & GLOB_QUOTE) {

*** end of patch

This changes behavior in the just the case where the prefix is two 
backslashes.  With the fix, the behavior is:

> Sys.glob("\\jacona\\home\\tplate")
character(0)
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("\\jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"

Without the fix, the behavior is:
> Sys.glob("\\jacona\\home\\tplate")
character(0)
> Sys.glob("jacona\\home\\tplate")
character(0)
> Sys.glob("\\jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"


Here is a corresponding change to the docs:

tpl...@oberon /cygdrive/c/Rbuild/R-2.9.1/src/library/base/man
*** Sys.glob.Rd~Thu Mar 19 17:05:24 2009
--- Sys.glob.Rd Mon Jun 29 13:52:57 2009
***
*** 89,94 
--- 89,104 
   File paths in Windows are interpreted with separator \code{\\} or
   \code{/}.  Paths with a drive but relative (such as \code{c:foo\\bar})
   are tricky, but an attempt is made to handle them correctly.
+   Backslashes in paths are tricky because they can serve dual purposes:
+   meta-function remover and path separator.  As a result, single or
+   double backslashes can serve as path separators.  UNC network drive
+   paths specified with backslashes (such as \code{foo\\bar}) are
+   treated specially so that the network drive is found when the path
+   begins with two, three, or four backslashes (i.e., paths beginning
+   with \code{foo\\bar}, \code{\\foo\\bar}, and
+   \code{\\foo\\bar} all result in the same output).  UNC network
+   drive paths can also be specified with two forward slashes.
+
 #endif
 }
 \value{
***
*** 117,122 
--- 127,138 
 \examples{
 \dontrun{
 Sys.glob(file.path(R.home(), "library", "*", "R", "*.rdx"))
+ # different ways of seeing the same network drive
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("//foo/bar")
 }}
 \keyword{utilities}
 \keyword{file}

*** end of patch

R comp

Re: [Rd] active bindings and ls.str

[Tony Plate]

Thomas Friedrichsmeier wrote:

On Tuesday 30 June 2009, Romain Francois wrote:
  

This was more of a question. I'd like to know if there is a way for
objects to broadcast that they have changed.
This would be very useful to for example implement an object browser in
a front-end, which I guess is part of the reason for the trick ?



Yes, that's around half the reason. The other half is our data.frame-editor, 
which tries to create the illusion of "in-place" editing. For that it's pretty 
important to keep the editor data in sync with R's version of the data.frame.


I would certainly like to see an easier way to detect changed objects as well.

  
I used active bindings for the same purpose (tracking changes to 
objects) in the package trackObjs.  Prior to using active bindings, I 
experimented with changes in the C code that added hooks to an 
environment so that an R function could be called when an object in the 
environment was created, changed or deleted.  This code was reasonably 
simple, and I'd be happy to share it if there is any interest (it was 
for R-2.4.1).


-- Tony Plate

The problem is as soon as you pass it to a function, you force the
promise, maybe passing the symbol instead could do the trick, but I have
not seen something that brings the information that an object is a
promise. Maybe you are right and I am not supposed to play with them ...



Yes, passing the symbol does the trick, indeed. (And until a few minutes ago, 
there was a regression in RKWard in just that respect.) 

I'll have to admit that we do play with the internals of promises in RKWard, 
too: When the only reason that we forced a promise was that the object browser 
stepped on it, we "put it back" to free up the memory, again. This works 
remarkably well, but in fact I don't think we are supposed to do this...


Regards
Thomas
  



__
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] Suggestion: Dimension-sensitive attributes

[Tony Plate]

There have been times when I've thought this could be useful too.

One way to go about it could be to introduce a special attribute that 
controls how attributes are dealt with in subsetting, e.g., 
"attr.dimname.like".  The contents of this would be character data; on 
subsetting, any attribute that had a name appearing in this vector would 
be treated as a dimension.  At the same time, it might be nice to also 
introduce "attr.keep.on.subset", which would specify which attributes 
should be kept on the result of a subsetting operation (could be useful 
for attributes that specify units).  This of course could be a way of 
implementing Henrik's suggestion: dimattr(x, "misc") <- value would add 
"misc" to the "attr.dimname.like" attribute and also set the attribute 
"misc".  The tricky part would be modifying the "[" methods.   However, 
the most useful would probably be the one for ordinary matrices and 
arrays, and others could be modified when and if their maintainers see 
the need.


-- Tony Plate

Bengoechea Bartolomé Enrique (SIES 73) wrote:

Hi,

I agree with Henrik that his suggestion to have "dimension vector attributes" 
working like dimnames (see below) would be an extremely useful infrastructure adittion to 
R.

If this is not considered for R-core, I am happy to try to implement this in a 
package, as a new class. And possibly do the same thing for data frames. Should 
you have any comments, ideas or suggestions about it, please share!

Best,

Enrique

-
Subject: 
From: Henrik Bengtsson Date: Sun, 07 Jun 2009 14:42:08 -0700


Hi, 

maybe this has been suggested before, but would it be possible, without not breaking too much existing code, to add other "dimension vector attributes" in addition to 'dimnames'? These attributes would then be subsetted just like dimnames. 

Something like this: 

  
x <- array(1:30, dim=c(2,3,5)) 
dimnames(x) <- list(c("a", "b"), c("a1", "a2", "a3"), NULL); 
dimattr(x, "misc") <- list(1:2, list(x=1:5, y=letters[1:8], z=NA), letters[1:5]); 




  
y <- x[,1:2,2:3] 
str(dimnames(y)) 



List of 3 


 $ : chr [1:2] "a" "b"
 $ : chr [1:2] "a1" "a2"
 $ : NULL


  
str(dimattr(x, "misc")) 



List of 3 
 $ : int [1:2] 1 2 
 $ :List of 2 
  ..$ x: int [1:5] 1 2 3 4 5 
  ..$ y: chr [1:8] "a" "b" "c" "d" ... 
 $ : chr [1:2] "b" "c" 

 I can imagine this needs to be added in several places and functions such as is.vector() needs to be updated etc. It is not a quick migration, but is it something worth considering for the future? 

/Henrik 


__
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] Rcmd check fails on Windows Samba network path in R 2.9.1

[Tony Plate]

This error message looks like it comes from 
src/library/tools/R/install.R, which contains the following test:


   if (!.file_test("-d", lib) || file.access(lib, 2L))
   stop("ERROR: no permission to install to directory ",
sQuote(lib), call. = FALSE)

The function .file_test() is defined earlier in the same file (it looks 
at file.info(lib)$isdir) and appears to be intended to be the same as 
utils:::file_test().


You could start trying to figure out what the problem is by trying these 
calls on the directory in question from an interactive R session.
(They seem to work as intended on my Windows system with a NetApp file 
system mounted on a letter drive.)


-- Tony Plate

Kevin R. Coombes wrote:

Hi,

I have just updated R from version 2.8.1 to version 2.9.1.  I am 
running Windows XP Professional, Service Pack 3.


With the update, I decided to update a set of packages that I maintain 
by compiling them for the new version.  Everything worked fine except 
for one package.  This package is unique (among the six I was working 
on) in that is stored on a UNIX-based file server that is exported to 
the Windows network via Samba.  The root of that network path is 
mapped to drive "N:" on the local machine.


'Rcmd check' fails for this package under 2.9.1.  The error message in 
'00install.out'  is:
"Error: ERROR: no permission to install to directory 
'N:/krc/Umpire/R-Package/Umpire.Rcheck'"


'Rcmd check' works for this package under 2.8.1.

'Rcmd check' works for this package if the directory is copied onto a 
local hard drive instead of the network drive.


'Rcmd build' and 'Rcmd build --binary' work under both versions.

It would be nice if someone could figure out what has changed and fix 
it


Best,
   Kevin Coombes

__
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] Rcmd check fails on Windows Samba network path in R 2.9.1

[Tony Plate]

Did you try starting up R-2.8.1 and checking the result of 
file.access(lib, 2) on that very same directory where R-2.9.1 gives an 
incorrect indication?  If that gives the correct answer, then, look for 
changes in the file.access code.


-- Tony Plate

Kevin R. Coombes wrote:

Hi,

The problem almost certainly has something to do with Samba.  We also 
have a NetApp file system, and copying the package source to that 
drive and running Rcmd check from Windows works just fine.


When running the commands from an interactive R session, file_test 
returns TRUE and file.access to test write permission indicates a 
failure, even though that information is incorrect.Here is a session 
transcript:


-
> getwd()
[1] "n:/krc/Umpire/R-Package"
> lib <- "Umpire.Rcheck"
> file_test("-d", lib)
[1] TRUE
> file.access(lib, 2)
Umpire.Rcheck
  -1
> dir.create(paste(lib, "testdir", sep='/'))
> dir(lib)
[1] "00check.log"   "00install.out" "testdir" > sessionInfo()
R version 2.9.1 (2009-06-26)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252


attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
----
Again, this all worked (and still works) correctly in 2.8.1.

   Kevin

Tony Plate wrote:
This error message looks like it comes from 
src/library/tools/R/install.R, which contains the following test:


   if (!.file_test("-d", lib) || file.access(lib, 2L))
   stop("ERROR: no permission to install to directory ",
sQuote(lib), call. = FALSE)

The function .file_test() is defined earlier in the same file (it 
looks at file.info(lib)$isdir) and appears to be intended to be the 
same as utils:::file_test().


You could start trying to figure out what the problem is by trying 
these calls on the directory in question from an interactive R session.
(They seem to work as intended on my Windows system with a NetApp 
file system mounted on a letter drive.)


-- Tony Plate

Kevin R. Coombes wrote:

Hi,

I have just updated R from version 2.8.1 to version 2.9.1.  I am 
running Windows XP Professional, Service Pack 3.


With the update, I decided to update a set of packages that I 
maintain by compiling them for the new version.  Everything worked 
fine except for one package.  This package is unique (among the six 
I was working on) in that is stored on a UNIX-based file server that 
is exported to the Windows network via Samba.  The root of that 
network path is mapped to drive "N:" on the local machine.


'Rcmd check' fails for this package under 2.9.1.  The error message 
in '00install.out'  is:
"Error: ERROR: no permission to install to directory 
'N:/krc/Umpire/R-Package/Umpire.Rcheck'"


'Rcmd check' works for this package under 2.8.1.

'Rcmd check' works for this package if the directory is copied onto 
a local hard drive instead of the network drive.


'Rcmd build' and 'Rcmd build --binary' work under both versions.

It would be nice if someone could figure out what has changed and 
fix it


Best,
   Kevin Coombes

__
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] can a key of a list be a variable

[Tony Plate]

Patterns like these can help to do what you want:

> lapply(setNames(1:3, paste("step", 1:3, sep="")), function(i) seq(i))
$step1
[1] 1

$step2
[1] 1 2

$step3
[1] 1 2 3

> setNames(list("the result"), paste("a", "name"))
$`a name`
[1] "the result"

>

-- Tony Plate

Bilel MASMOUDI wrote:

Hi,

I search a solution to record data in dynamic structures in R.
I have an algorithm that will be executed each step and whose output is an
array of doubles with unknown size.

The solution I found is to use lists
1) I initialise my list
 l <- list()
2) and at a step numbered i I conacatain the new tab to the list
vect <- algorithm()
l <<--c( l , list(stepi=vect))

The problem is that the key "stepi" is here a constant, I'd like to use a
variable like this
x = paste("step",index,sep="") where index is the last index (i)
l <<--c( l , list(x=vect)) --> this doesn't function, the key is named "x"
not "stepi"
If I write l <<--c( l , list(paste("step",index,sep="") =vect)), I receive
an error

Many thanks for your help



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Documentation for is.atomic and is.recursive

[Tony Plate]

Duncan Murdoch wrote:

On 02/09/2009 4:10 PM, Stavros Macrakis wrote:
Let us stipulate that the current wording can be construed to be 
correct.


I'd rather just state that the current wording is correct, without the 
weasel words.



I would nonetheless claim that the documentation as currently written
is at best ambiguous and confusing, and would benefit from improved
wording.


A claim that documentation would benefit from improved wording is a 
tautology.  A claim that the documentation is ambiguous requires more 
evidence than you've offered.  You have demonstrated that someone 
could be confused when reading it, but that isn't necessarily our 
responsibility.


Duncan Murdoch

I suspect the confusion comes from the mistaken, but very 
understandable, interpretation that the phrase "'x' is a vector" in the 
documentation should somehow equate with the R function call 
'is.vector(x)'.  Similar potentially misleading wording appears in the 
"Description" for ?is.vector:
  "|is.vector| returns |TRUE| if |x| is a vector (of mode logical, 
integer, real, complex, character, raw or list if not specified) or 
expression and |FALSE|".

However, the Details for ?is.vector do clarify, saying:
 "|is.vector| returns |FALSE| if |x| has any attributes except names."

Here are some concrete suggestions for improving the documentation:
(1) In the Details or Note section for ?is.atomic, add the paragraph:
"is.atomic is unaffected by the presence of attributes on 'x', unlike 
is.vector (which would probably be better named is.bare.vector).  
is.atomic(x) merely tests whether the data mode of x is an atomic vector 
type, and ignores whether or not x has attributes.  The behavior of 
is.vector(x) is quite different -- it tests whether x is a bare vector.  
is.vector can be TRUE for lists and expressions as well as atomic vector 
types, but if there are attributes other than names on x, is.vector(x) 
returns FALSE."


(2) In the Description section for ?is.vector, change
 "|is.vector| returns |TRUE| if |x| is a vector (of mode logical, 
integer, real, complex, character, raw or list if not specified) or 
expression"

to
 "|is.vector| returns |TRUE| if |x| is a bare vector (of mode logical, 
integer, real, complex, character, raw or list if not specified, with no 
attributes other than names), or expression with no attributes other 
than names"


-- Tony Plate



What would be lost by that?

One could argue that in R's pre-history we should have had is.atomic 
imply

is.vector, but that's not how things are documented, and I think we're
pretty much stuck with the definitions we've got on low level 
functions like

those.


I explicitly said in my mail that I was not suggesting that past
design decisions (wise or unwise) be revisited; only that they be
documented more clearly.

   -s

On Wed, Sep 2, 2009 at 3:37 PM, Duncan Murdoch 
wrote:

On 9/2/2009 2:39 PM, Stavros Macrakis wrote:

The documentation for is.atomic and is.recursive is inconsistent with
their behavior in R 2.9.1 Windows.

? is.atomic

'is.atomic' returns 'TRUE' if 'x' is an atomic vector (or 'NULL')
and 'FALSE' otherwise.
...
'is.atomic' is true for the atomic vector types ('"logical"',
'"integer"', '"numeric"', '"complex"', '"character"' and '"raw"')
and 'NULL'.

This description implies that is.atomic(x) implies is.vector(x)
(assuming that an "atomic vector type" is a subset of a "vector
type").  But in fact that is not true for values with class
attributes:
I don't see is.vector mentioned there.  The description of is.vector 
on its

own man page implies the behaviour below; I think the description of
is.atomic that you quote above is also consistent with the behaviour.

One could argue that in R's pre-history we should have had is.atomic 
imply

is.vector, but that's not how things are documented, and I think we're
pretty much stuck with the definitions we've got on low level 
functions like

those.



is.atomic(factor(3)) => TRUE
is.vector(factor(3)) => FALSE

is.atomic(table(3)) => TRUE
is.vector(factor(3)) => FALSE

It appears, then, that is.atomic requires only that unclass(x) be an
atomic vector, not that x be an atomic vector.

There is also another case where is.atomic(x) != 
is.vector(unclass(x)):


is.atomic(NULL) => TRUE
is.vector(NULL) => FALSE

It would be useful to make the documentation consistent with the
implementation. (Presumably by updating the documentation, not
changing the behavior.)

The documentation continues:

'is.recursive' returns 'TRUE' if 'x' has a recursive (list-like)
 

Re: [Rd] weigths in nls (PR#13991)

[Tony Plate]

This is expected behavior from the way nls() is written.  The nls() 
function has a "..." argument, which means that additional arguments are 
allowed.


Under "Arguments" the docs say:
|...|   Additional optional arguments. None are used at present.


As far as I can see in the code, nothing at all is done with the 
additional arguments (consistent with the docs).   I guess the "..." 
argument is there to allow for future development (though I'm not sure 
what is gained by including "..." as a formal argument now, and not just 
adding it in the future if and when it is needed.)


In general, the use of ... arguments does add flexibility, but it takes 
away some error-checking.


-- Tony Plate

stephen.b...@cibc.com wrote:

Potential bug:

I mistyped weights in the call ('weigths') and it did not produce any error=
 message. The coefs were exactly the same like without weights, so I was su=
spicious and when weights(nls1) gave NULL, I saw my typo.

Usually the function will say "Unused arguments", which shows you the error=
, but not nls.

Regards
Stephen

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] what should NCOL(NULL) return?

[Tony Plate]

Hiroyuki Kawakatsu wrote:

Hi,

I get (using r50188)

  

nrow(NULL)


NULL
  

NROW(NULL)


[1] 0
  

ncol(NULL)


NULL
  

NCOL(NULL)


[1] 1

The last seems 'wrong' to me, though matrix(NA, 0, 1) appears to be
well defined.
  

Seems consistent with the documentation, which says:


 Description

|nrow| and |ncol| return the number of rows or columns present in |x|. 
|NCOL| and |NROW| do the same treating a vector as 1-column matrix.


Based on ?NCOL alone, I guess one might be able to quibble about how 
NULL should be treated, as the docs do describe the argument as "x a 
vector, array or data frame."  However, it's pretty common for functions 
that work with vectors and arrays to treat NULL the same as numeric(0).


-- Tony Plate

  

blackhole = matrix(NA, 0, 1)
blackhole[,1] = 5
blackhole


 [,1]

h.



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug in `pmatch' (error with too long 'choices')?

[Tony Plate]

I believe the answer is that you are missing something: partial matching.

The 651'st elt of colors() is "whitesmoke", so it is ambiguous whether 
"whit" matches "white" or "whitesmoke". When you leave out the 651'st 
elt, "whit" happily matches "white".


> which(substring(colors(), 1, 4)=="whit")
[1] 1 651
> colors()[which(substring(colors(), 1, 4)=="whit")]
[1] "white" "whitesmoke"
> match.arg("whit", colors()[1:650])
[1] "white"
> match.arg("whit", colors())
Error in match.arg("whit", colors()) :
'arg' should be one of “white”, “aliceblue”, ...
> match.arg("whit", colors()[c(1,651)])
Error in match.arg("whit", colors()[c(1, 651)]) :
'arg' should be one of “white”, “whitesmoke”
>

-- Tony Plate

Joerg van den Hoff wrote:

I observed the following:

match.arg("white", colors()) 


yields 'white', but

match.arg("whit", colors())

yields:

`Error in match.arg("whit", colors()) : 
  'arg' should be one of "white", "aliceblue", '...


this message actually comes from `pmatch'. using a suitable subset of
`colors()' works OK. the precise length were the error occurs seems to
depend on `arg' and `choices'. e.g.

match.arg("whit", colors()[1:650])

works

but the limit seems not be fixed. in another setting it
happend around a length of `choices' of around 130. maybe a memory management 
related
bug? or am I missing something?

regards,
joerg



platform   powerpc-apple-darwin8.11.1  
arch   powerpc 
os darwin8.11.1
system powerpc, darwin8.11.1   
status 
major  2   
minor  9.2 
year   2009
month  08  
day24  
svn rev49384   
language   R   
version.string R version 2.9.2 (2009-08-24)


__
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] inconsistent behavior for logical vectors when using apply (" TRUE")

[Tony Plate]

This happens in as.matrix(), which gets called by apply().

When you've got a mixed-mode dataframe like this, as.matrix() converts 
everything to character.  But, the rules it uses for each column don't 
seem to be entirely consistent regarding whether columns are 
space-padded to make each element have the same number of characters.


The way it works out, logical mode columns are passed through format(), 
which space-pads by default.  Factor columns are passed through 
as.vector(), and character-mode columns are left alone.  The result is 
that some columns come out space-padded, and some don't, depending on 
their original mode.


To get greater control of this, you theoretically should be able to do 
something like apply(as.matrix(format(X, justify="none")), ...),
except that format() seems to ignore the justify argument for logical 
vectors, e.g.:

> format(c(T,F,T))
[1] " TRUE" "FALSE" " TRUE"
> format(c(T,F,T), justify="none")
[1] " TRUE" "FALSE" " TRUE"
>

If it's really important for you to get this to work the way you want, 
you can convert the logical column of the data frame using as.character 
(see the end of the example below).


Here's an example that shows probably far more than you wanted to know:

> X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE), 
codef=c("a","ab","abcd"), codec=I(c("x", "xy", "xyz")))

> sapply(X, class)
 letters  flag codef codec
"factor" "logical"  "factor""AsIs"
> as.matrix(X)
letters flagcodef  codec
[1,] "a" " TRUE" "a""x" 
[2,] "b" "FALSE" "ab"   "xy"

[3,] "c" " TRUE" "abcd" "xyz"
> unclass(format(X))
$letters
[1] "a" "b" "c"

$flag
[1] " TRUE" "FALSE" " TRUE"

$codef
[1] "a""ab"   "abcd"

$codec
[1] "x"   "xy"  "xyz"

attr(,"row.names")
[1] "1" "2" "3"
> unclass(format(X, justify="left"))
$letters
[1] "a" "b" "c"

$flag
[1] " TRUE" "FALSE" " TRUE"

$codef
[1] "a   " "ab  " "abcd"

$codec
[1] "x  " "xy " "xyz"

attr(,"row.names")
[1] "1" "2" "3"
>
> # The only way I can see to get the logical column converted to 
character without padding:

> X1 <- X
> X1$flag <- as.character(X1$flag)
> as.matrix(X1)
letters flagcodef  codec
[1,] "a" "TRUE"  "a""x" 
[2,] "b" "FALSE" "ab"   "xy"

[3,] "c" "TRUE"  "abcd" "xyz"
>

Adrian Dragulescu wrote:


Hello,


X <- data.frame(letters=letters[1:3], flag=c(TRUE, FALSE, TRUE))
X

  letters  flag
1   a  TRUE
2   b FALSE
3   c  TRUE

apply(X, 1, as.list)

[[1]]
[[1]]$letters
[1] "a"

[[1]]$flag
[1] " TRUE"


[[2]]
[[2]]$letters
[1] "b"

[[2]]$flag
[1] "FALSE"


[[3]]
[[3]]$letters
[1] "c"

[[3]]$flag
[1] " TRUE"

Notice how TRUE becomes " TRUE" and FALSE becomes "FALSE".  Not sure 
why TRUE gets an extra whitespace in front.


Checked with R-2.10.0, but can reproduce the behavior as far back as 
R-2.8.1.


Adrian Dragulescu


sessionInfo()

R version 2.10.0 (2009-10-26)
i386-pc-mingw32

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United 
States.1252

[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] tools_2.10.0

__
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] Active bindings in attached environments

[Tony Plate]

An explanation of this would be nice in ?makeActiveBinding, e.g.,

NOTE:

When an environment is attach()'ed to the search path, any active 
bindings in it are not preserved as active bindings.  This happens 
because attach() actually adds a new environment to the search path, and 
copies objects into it.  Thus, active bindings are evaluated and their 
values copied into the attached environment.


(Is this explanation correct?)

-- Tony Plate

(PS: Thunderbird wants to spell-correct "makeActiveBinding" to 
"vindictivenesses", which seems an amusingly appropriate allusion to the 
nature of this "gotcha" :-)


Jeffrey Horner wrote:

On Thu, Nov 5, 2009 at 9:53 AM, Jeffrey Horner  wrote:
  

Hi,

Is this expected behavior for active bindings in attached
environments, or is this a bug:



e <- new.env()
makeActiveBinding('x',function() 'foo',e)
ls(e)
  

[1] "x"


attach(e)
search()
  

[1] ".GlobalEnv""e" "package:graphics"
[4] "package:grDevices" "package:datasets"  "package:utils"
[7] "package:methods"   "Autoloads" "package:base"


x
  

function() 'foo'

Should this print 'foo' ? The following works as I would expect:



with(e,x)
  

[1] "foo"

but this doesn't:



f <- function() x
f()
  

function() 'foo'

However, changing the environment of f does:



environment(f) <- e
f()
  

[1] "foo"



Actually, it is my understanding of attach() which is the bug. The
attach documentation clearly states that a copy of the object is
attached, not the object itself.

Thanks,

Jeff
--
http://biostat.mc.vanderbilt.edu/JeffreyHorner

__
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] typo in docs for unlink()

[Tony Plate]

The VALUE section in the help for 'unlink' says:

|  0| for success, |1| for failure. Not deleting a non-existent file is 
not a failure, nor is being unable to delete a directory if |recursive = 
FALSE|. However, missing values in |x| result are regarded as failures.


The last phrase doesn't make sense to me.  Should it be either "missing 
values in x are regarded as failures" or "missing values in x result in 
failure" ?


Also, after reading the docs, I'm still unable to work out if unlink() 
will return 1 when the user tries to recursively delete a directory on 
systems that don't support recursive=T.


The DETAILS section says "recursive=TRUE is not supported on all 
platforms, and may be ignored, with a warning", which could be 
interpreted as implying no special action when recursive=TRUE is not 
implemented (other than a warning()), and the VALUE section doesn't say 
what the return value will be under such conditions.


I've skimmed the various *_unlink functions in src/main/platform.c, and 
it looks like they all implement recursive=TRUE, so I'm still in the 
dark about the required behavior on systems that don't support it.  
Could this be clarified in the help file?


thanks,

Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] typo in docs for unlink()

[Tony Plate]

PS, I should have said that I'm reading the docs for unlink in R-2.10.0 
on a Linux system.  The docs that appear in a Windows installation of R 
are different (the Windows docs do not mention that not all systems 
support recursive=TRUE).


Here's a plea for docs to be uniform across all systems!  Trying to 
write R code that works on all systems is much harder when the docs are 
different across systems, and you might only see system specific notes 
on a different system than the one you're working on.


-- Tony Plate

Tony Plate wrote:

The VALUE section in the help for 'unlink' says:

|  0| for success, |1| for failure. Not deleting a non-existent file 
is not a failure, nor is being unable to delete a directory if 
|recursive = FALSE|. However, missing values in |x| result are 
regarded as failures.


The last phrase doesn't make sense to me.  Should it be either 
"missing values in x are regarded as failures" or "missing values in x 
result in failure" ?


Also, after reading the docs, I'm still unable to work out if unlink() 
will return 1 when the user tries to recursively delete a directory on 
systems that don't support recursive=T.


The DETAILS section says "recursive=TRUE is not supported on all 
platforms, and may be ignored, with a warning", which could be 
interpreted as implying no special action when recursive=TRUE is not 
implemented (other than a warning()), and the VALUE section doesn't 
say what the return value will be under such conditions.


I've skimmed the various *_unlink functions in src/main/platform.c, 
and it looks like they all implement recursive=TRUE, so I'm still in 
the dark about the required behavior on systems that don't support 
it.  Could this be clarified in the help file?


thanks,

Tony Plate

__
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] error checks

[Tony Plate]

Putting options(error=function() NULL) at the start of the .R will let R 
CMD check continue with commands in a file after stop() is called.  (Or 
anything other than the default options(error=NULL)).


-- Tony Plate


Terry Therneau wrote:

 I'm currently packaging up some of the kinship matrix routines more
formally, these are used in coxme when dealing with family correlation
structures.  One of my test programs exercises error conditions, i.e.,
it purposely feeds particular types of invalid pedigree data in to see
if the right error message results.  So there are comment-action pairs
# the next line should generate a "pedigree loop" error
kindepth(.

As I found out last night, such tests case a failure of R CMD check!
Any suggestions on how to properly package these?

 A second question is keywords.  None of the standard ones apply to this
code -- I'd like "genetics".  How do we add a new one?  


Terry T.

__
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] Surprising length() of POSIXlt vector (PR#14073)

[Tony Plate]

maech...@stat.math.ethz.ch wrote:

"PD" == Peter Dalgaard 
on Fri, 20 Nov 2009 09:54:34 +0100 writes:



PD> m...@celos.net wrote:
>> Arrays of POSIXlt dates always return a length of 9.  This
>> is correct (they're really lists of vectors of seconds,
>> hours, and so forth), but other methods disguise them as
>> flat vectors, giving superficially surprising behaviour:
>> 
>> strings <- paste('2009-1-', 1:31, sep='')

>> dates <- strptime(strings, format="%Y-%m-%d")
>> 
>> print(dates)

>> #  [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
>> #  [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
>> # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
>> # [31] "2009-01-31"
>> 
>> print(length(dates))

>> # [1] 9
>> 
>> str(dates)

>> # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03" 
"2009-01-04" ...
>> 
>> print(dates[20])

>> # [1] "2009-01-20"
>> 
>> print(length(dates[20]))

>> # [1] 9
>> 
>> I've since realised that POSIXct makes date vectors easier,

>> but could we also have something like:
>> 
>> length.POSIXlt <- function(x) { length(x$sec) }
>> 
>> in datetime.R, to avoid breaking functions (like the

>> str.POSIXt method) which use length() in this way?


PD> [You need "wishlist" in the title for this sort of stuff.]

PD> I'd be wary of this. Just the other day we found that identical() broke 
PD> on some objects because a package had length() redefined as a class 
PD> method. I.e. the danger is that something wants to use length() with its 
PD> original low-level interpretation.


Yes, of course.
and Romain mentioned  str().  Note that we have needed to define
a "POSIXt" method for str(), partly just *because* of the
current anomaly:
As Tony Plate, e.g., has argued, entirely correctly in my view,
the anomaly is thatlength() and "["   are not compatible;
and while I think no R language definition says that they should
be, I still believe that you need very good reasons for them to
be incompatible, as they are for POSIXlt.

In the current case, for me the only good reason is backwards
compatibility.
My personal taste would be to change it and see what happens.
I would be willing to clean up after that change within R 'base'
and all packages I am coauthoring (quite a few), but of course
there are still a thousand more R packages..
My strong bet would be that less than 1% would be affected,
and my point guess for the percentage affected would be
rather in the order of  1/1000.

The question is if we (you too!), the R community, are willing to
bear the load of cleanup, after such a change which would really
*improve* consistency of that small corner of R.
For me, as I indicated above, I am willing to bear my share
(and actually have got it ready for R-devel)
  
Would be great to see this change!  Surely the right way to do things is 
that functions that wish to examine the low level structure of S3 
objects should use unclass() before looking at length and elements, so 
there's no reason for a class such as POSIXlt to not provide a 
logical-level length method.


At a broader level, when I've designed vector/array classes, I've 
wondered what methods I should define, but have been unable to find any 
specification of a set of methods.  When one thinks about it, there are 
actually quite a set of strongly-connected methods with quite a lot a 
behaviors to implement, e.g., length, '[' (with logical, numeric & 
character indicies, including 0 and NA possibilities), '[[', 'c', and 
then optionally 'names', and then for multi-dim objects, 'dim', 
'dimnames', etc.  Consequently, last time this discussion on length and 
'[' methods POSIXlt came up, I wrote a function that automatically 
tested behavior of all these methods on a specified class and summarizes 
the behavior.  If anyone is interested in such a thing, I'd be happy to 
dig it up and distribute it (I'd attach it to this message, but I'm on 
vacation and don't have access to the compute that I think it's on.)


-- Tony Plate


Martin Maechler, ETH Zurich (and R Core Team)

__
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] documentation omission in Extract.Rd?

[Tony Plate]

The help file for "[<-" (and "[[<-" doesn't contain those functions in 
it's usage section ( .../src/library/base/man/Extract.Rd ).  Although 
that file lists "[<-" and "[[<-" as aliases, it doesn't document them in 
a formal manner (consequently, the "value" argument is not described in 
the "arguments" section.)


Is this an oversight, or are those documented elsewhere?  In contrast, 
src/library/base/man/Extract.factor.Rd does contain the replacement 
forms in its usage section (as does Extract.data.frame.Rd)


Also, Extract.Rd uses forms like "x[i, j, \dots , drop = TRUE]" in the 
usage section, while Extract.factor.Rd uses the "method" syntax: 
"\method{[}{factor}(x, \dots, drop = FALSE)".  Is this because the 
"method" syntax is not appropriate for the default methods that are 
documented in Extract.Rd, or is the source of the docs not up-to-date 
with the latest Rd syntax?  I ask because I was looking for examples of 
how to write documentation for extraction and replacement functions.


This is based on looking at the source code at 
http://svn.r-project.org/R/trunk/src/library/base/man/Extract.Rd and I 
see the same in R-2.10.0 for Linux.


-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] extraction of sub-matrix by name

[Tony Plate]

This is documented behavior. From ?"[.data.frame":

Both ‘[’ and ‘[[’ extraction methods partially match row
names. By default neither partially match column names, but
‘[[’ will unless ‘exact=TRUE’. If you want to do exact
matching on row names use ‘match’ as in the examples.

In the history of S, S-PLUS and R partial matching for subscripts and 
indices has been used in many places, but over time it has been removed 
from some. Some methods for "[[" have an "exact" argument that allows 
specification of whether you want exact or prefix matches. However, as 
the docs indicate, this doesn't apply to "[" for rownames in data 
frames. At this point, the behavior is unlikely to change -- it risks 
breaking too much old code (that's just my opinion based on observation 
of the evolution of R -- I have no control over that evolution). Follow 
the suggestion in the help for [.data.frame to get exact matching.


-- Tony Plate

Yurii Aulchenko wrote:

Dear all,

sorry to bother you with potentially known issue --

we have noticed that if we select data frame rows by rownames, we get 
some results back if the match can be done unambiguously, though the 
match is not perfect (see example), e.g. x{"2",] will return a row if 
there is a unique row with name starting with "2" (but may be "2375745"!)


is that a planned behavior of R which will be maintained? for us it 
was a bit unexpected...


Yurii

-
> a <- data.frame(x=1:3, y=1:3)
> rownames(a) <- c("2535","59617","555")
> a
x y
2535 1 1
59617 2 2
555 3 3
> a["5",]
x y
NA NA NA
> a["555",]
x y
555 3 3
> a["2",]
x y
2535 1 1
> version
_
platform i386-apple-darwin9.8.0
arch i386
os darwin9.8.0
system i386, darwin9.8.0
status Under development (unstable)
major 2
minor 11.0
year 2009
month 12
day 07
svn rev 50688
language R
version.string R version 2.11.0 Under development (unstable) 
(2009-12-07 r50688)


---
Yurii Aulchenko
Erasmus MC Rotterdam
Department of Epidemiology, Ee 2200
Postbus 2040, 3000 CA Rotterdam
The Netherlands

phone: +31107043486
fax: +31107044657

__
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] binary string conversion to a vector (PR#14120)

[Tony Plate]

Just responding to some of the issues in this long post:

(1) Don't rely on the printed form of an object to decide whether or not 
they are identical.  The function str() is very useful in this regard, 
and sometimes also unclass().  To see whether two object are identical, 
use the function identical()


> qvector <- c("0", "0", "0", "1", "1", "0", "1")
> qvector[1]
[1] "0"
> noquote(qvector[1])
[1] 0
> str(noquote(qvector[1]))
Class 'noquote'  chr "0"
> as.integer(qvector[1])
[1] 0
> str(as.integer(qvector[1]))
int 0
> identical(noquote(qvector[1]), as.integer(qvector[1]))
[1] FALSE
>

Does this alleviate the concern as to the possibility of a bug in 
noquote/as.integer? Or were there deeper issues?


(2) to see how some other users of R have package up miscellaneous 
functions that might be of use to other people, look for packages on 
CRAN with "misc" in their names -- I see almost 10 of them.  The problem 
with just posting snippets of code is that they get lost in all the 
other posts here, and many long term R users have dozens if not hundreds 
of their own functions that are streamlined for their own frequent tasks 
and style of programming.


(3) sounds like a great idea to use R to bring statistical rigor into 
the analysis of the performance of combinatorial optimization algorithms!


(4) install.packages("stringr") works fine for me.  Maybe it was a 
temporary glitch?  Have you checked whether you have a valid repository 
selected?  E.g., I have in my .Rprofile:
options(repos=c(CRAN="http://cran.cnr.Berkeley.edu"; , 
CRANextra="http://www.stats.ox.ac.uk/pub/RWin";))


Enjoy learning R!

-- Tony Plate

Franc Brglez wrote:

Hello!
 
Please accept my sincere apologies for annoying the R development team with my post this week. If I were required to register as "a developer" before submission, this would not have happened. To rehabilitate myself, please find at the bottom of this mail two R-functions, 'string2vector' and 'vector2string', with "comments and tests". Both functions may go a long way towards assisting a number of R-users to make their R-programming more productive. I am a novice R-programmer: I started dabbling in R less than two months ago, heavily influenced by examples of code I see, including within the R.org documents (monkey does what monkey sees). Before posting two functions, I would really appreciate constructive edits where they may be needed as well as their posting by someone-in-the-know so there will be conveniently accessible for R users.


I am very impressed with potential of R and the community supporting it. I just wish I 
got to R sooner: I am looking to R to better support my work in "designed 
experiments to assess the statistically significant performance of combinatorial 
optimization algorithms on instance isomorphs of NP-hard problems" -- for better 
context of this mouthful, see the few postings under
  http://www.cbl.ncsu.edu:16080/xBed/publications/
I am working on a tutorial paper where I expect R to play a significant role in 
better explaining and illustrating, code-wise and graphically, the concepts 
discussed in the publications above. I would welcome a co-author with 
experience in R-programming as well as statistics and interests in the 
experimental methods addressed in these publications.

As I elaborate in notes that follow, I was looking at a variety of "R-documents" before 
my "bug" submission. I would appreciate very much if some of you could take the time to 
scan through these notes and respond briefly with useful pointers. Here are the headlines:

(1) why I still think there may be a bug with 'noquote' vs 'as.integer'

(2) search on "split string" and "join string"; the missing package 
"stringr"

(3) a take on "Tcl" commands 'split', 'join', 'string', 'append', 'foreach'

(4) a take on "R" functions 'string2vector' and 'vector2string'

(5) code and comments for "R" functions 'string2vector' and 'vector2string

(1) why I still think there may be a bug with 'noquote' vs 'as.integer'

  

# MacOSX 10.6.2, R 2.9.1 GUI 1.28 Tiger build 32-bit (5444)
qvector


[1] "0" "0" "0" "1" "1" "0" "1"
  

qvector[1]


[1] "0"
  

tmp = noquote(qvector[1])
tmp


[1] 0
  

tmp = as.integer(qvector[1])
tmp


[1] 0
  
When embedded in the function as per my "bug" report, 'noquote' and 'as.integer' are no long

Re: [Rd] as.Date function yields inconsistent results (PR#14166)

[Tony Plate]

I think you're right that this is a timezone issue -- it seems to be a 
consequence of the behavior described about in the article by Gabor 
Grothendieck and Thomas Petzoldt: "R help desk: Date and time classes in 
R." R News, 4(1):29-32, June 2004. 
  
http://cran.r-project.org/doc/Rnews/Rnews_2004-1.pdf


(there is a reference at 
http://wiki.r-project.org/rwiki/doku.php?id=guides:times-dates)


BEGIN QUOTE from p31 http://cran.r-project.org/doc/Rnews/Rnews_2004-1.pdf

Regarding POSIX classes, the user should be aware of the following:
...
* POSIXlt.  The tzone attribute on POSIXlt times are ignored so it is 
safer to use POSIXct than POSIXlt when performing arithmetic or other 
manipulations that may depend on time zones.


END QUOTE

The ignoring of the tzone attribute appears to apply to as.Date() 
conversions too.  The behavior is especially interesting because POSIXlt 
objects are converted to POSIXct objects by arithmetic, and the 
arithmetic operation preserves the tzone attribute.  So, if you want 
as.Date() to pay attention to the tzone attribute of a POSIXlt object, 
you might be able to just add 0 to it (or just use as.POSIXct() on it).  
(Though I don't know if there are other pitfalls in this path to catch 
the unwary).  The following demonstrates various aspects of the behavior:



> d.ct.CET <- as.POSIXct("1999-03-18", tz="CET")
> d.lt.CET <- as.POSIXlt("1999-03-18", tz="CET")
> d.ct.UTC <- as.POSIXct("1999-03-18", tz="UTC")
> d.lt.UTC <- as.POSIXlt("1999-03-18", tz="UTC")
> d.ct.EST <- as.POSIXct("1999-03-18", tz="EST")
> d.lt.EST <- as.POSIXlt("1999-03-18", tz="EST")
> # ii is hours to catch the date changes in the time-zones here
> ii <- c(0,1,19,20,23,24)*3600
> # all columns of x1 are as.Date() of POSIXct objects
> # each column follows its tzone attribute because as.Date() pays
> # attention to tzone attr of POSIXct object, and arithmetic converts
> # POSIXlt object to POSIXct object preserving the tzone attr
> (x1 <- data.frame(hour=ii, ct.UTC=as.Date(d.ct.UTC + ii), 
lt.UTC=as.Date(d.lt.UTC + ii), ct.CET=as.Date(d.ct.CET + ii), 
lt.CET=as.Date(d.lt.CET + ii), ct.EST=as.Date(d.ct.EST + ii), 
lt.EST=as.Date(d.lt.EST + ii)))

  hour ct.UTC lt.UTC ct.CET lt.CET ct.EST lt.EST
1 0 1999-03-18 1999-03-18 1999-03-17 1999-03-17 1999-03-18 1999-03-18
2  3600 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-18
3 68400 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-19
4 72000 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-19
5 82800 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-19
6 86400 1999-03-19 1999-03-19 1999-03-18 1999-03-18 1999-03-19 1999-03-19
> all.equal(x1$lt.UTC, x1$ct.UTC)
[1] TRUE
> all.equal(x1$lt.CET, x1$ct.CET)
[1] TRUE
> all.equal(x1$lt.EST, x1$ct.EST)
[1] TRUE
> class(d.lt.EST)
[1] "POSIXt"  "POSIXlt"
> class(d.lt.EST + ii)
[1] "POSIXt"  "POSIXct"
> as.POSIXlt(d.lt.EST + ii)
[1] "1999-03-18 00:00:00 EST" "1999-03-18 01:00:00 EST"
[3] "1999-03-18 19:00:00 EST" "1999-03-18 20:00:00 EST"
[5] "1999-03-18 23:00:00 EST" "1999-03-19 00:00:00 EST"
>
> # the lt.* columns of x2 are as.Date() of POSIXlt objects, and these
> # are all the same the ct.UTC column because as.Date() ignores the
> # tzone attribute of POSIXlt objects
> (x2 <- data.frame(hour=ii, ct.UTC=as.Date(d.ct.UTC + ii), 
lt.UTC=as.Date(as.POSIXlt(d.lt.UTC + ii)), ct.CET=as.Date(d.ct.CET + 
ii), lt.CET=as.Date(as.POSIXlt(d.lt.CET + ii)), ct.EST=as.Date(d.ct.EST 
+ ii), lt.EST=as.Date(as.POSIXlt(d.lt.EST + ii

  hour ct.UTC lt.UTC ct.CET lt.CET ct.EST lt.EST
1 0 1999-03-18 1999-03-18 1999-03-17 1999-03-18 1999-03-18 1999-03-18
2  3600 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-18
3 68400 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-18
4 72000 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-18
5 82800 1999-03-18 1999-03-18 1999-03-18 1999-03-18 1999-03-19 1999-03-18
6 86400 1999-03-19 1999-03-19 1999-03-18 1999-03-19 1999-03-19 1999-03-19
> all.equal(x2$lt.UTC, x2$ct.UTC)
[1] TRUE
> all.equal(x2$lt.CET, x2$ct.UTC)
[1] TRUE
> all.equal(x2$lt.EST, x2$ct.UTC)
[1] TRUE
>
> sessionInfo()
R version 2.10.1 (2009-12-14)
i486-pc-linux-gnu

locale:
[1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C 
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8   
[5] LC_MONETARY=C  LC_MESSAGES=en_US.UTF-8  
[7] LC_PAPER=en_US.UTF-8   LC_NAME=C
[9] LC_ADDRESS=C   LC_TELEPHONE=C   
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C  


attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


loaded via a namespace (and not attached):
[1] tools_2.10.1
>
>


diver...@univecom.ch wrote:

Full_Name: Mario Luoni
Version: 2.10.0
OS: Windows XP HE SP3
Submission from: (NULL) (217.194.59.134)


This piece of code:

zzz1 <

Re: [Rd] function curve() (PR#14191)

[Tony Plate]

You may have figured this out already, but you can get a "call" object 
from parse() by extracting its first element, as in


mycurveC <-
function(x,from=1,to=10){
   xloc <- parse(text=x)[[1]]
   do.call("curve",list(expr=xloc,from=from,to=to))
}
mycurveC("(x-4) ** 2")

This doesn't address the confusion you note, but it is an easy way of 
getting your code to work without needing any functions to be redefined.


-- Tony Plate

georgi.boshna...@manchester.ac.uk wrote:

Full_Name: Georgi Boshnakov
Version: 2.10.1pat
OS: Windows XP
Submission from: (NULL) (130.88.123.205)


When calling programmatically function curve() from package:graphics I
experienced some trouble since it reports
stop("'expr' must be a function or an expression containing 'x'")
even if expr is "expression". Naturally, the user message uses "expression"  in
its usual generic meaning but it is somewhat confusing that an object of type
"expression" is rejected.

The message is produced in the following piece in the source of function
curve()

else {
if (!(is.call(sexpr) && match("x", all.vars(sexpr), nomatch = 0L))) 
stop("'expr' must be a function or an expression containing 'x'")

expr <- sexpr
if (is.null(ylab)) 
ylab <- deparse(sexpr)

}

The "if" statement only checks with is.call, and not with is.expression.
Maybe it is worth including  the check with is.expression, e.g. as in

else {
if (!((is.call(sexpr) || is.expression(sexpr)) &&
  match("x", all.vars(sexpr), nomatch = 0L)
  ))
   stop("'expr' must be a function or an expression containing 'x'")
expr <- sexpr
if (is.null(ylab)) 
ylab <- deparse(sexpr)

}


Example:

# use curve()
mycurveA <-
function(x,from=1,to=10){
xloc <- parse(text=x)
# call("mycurve0",expr=xloc,from=from,to=to)
do.call("curve",list(expr=xloc,from=from,to=to))
}

# use curve modified as suggested above.
mycurveB <-
function(x,from=1,to=10){
xloc <- parse(text=x)
# call("mycurve0",expr=xloc,from=from,to=to)
do.call("mycurve0",list(expr=xloc,from=from,to=to))
}

  

mycurveA("x^2")

Error in curve(expr = expression(x^2), from = 1, to = 10) : 
  'expr' must be a function or an expression containing 'x'


  

mycurveB("x^2")


#  (no error, plots the graph)


Best regards,
Georgi Boshnakov

__
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] 00LOCK and nfs

[Tony Plate]

I have some tools and an R package that together provide a solution to 
the problem of updating an R package while it is attached in one or more 
running R sessions (whether on the same machine or not.)  The technique 
is to always create a new directory for the newly installed package, so 
that existing installed packages are never overwritten.  The tricky part 
is to manage this in a way that is transparent to the user, which is 
what the package accomplishes.  If this is any interest in this I could 
make it available; email me privately or respond on the list.


-- Tony Plate

On 4/26/2010 1:05 PM, Kasper Daniel Hansen wrote:

2010/4/26 Christian Brechbühler:
   


On Mon, Apr 26, 2010 at 11:15 AM, Kasper Daniel Hansen
  wrote:
 

I am running into a problem with the 00LOCK file and .nfs files.  It
seemed to be caused by the following
  R is installed on NFS
  user A has loaded pkg_A containing a dynamically loaded library
  user B (the administrator) runs install.packages("pkg_A")
  as the final part of the installation process the 00LOCK directory is
removed
  this creates a .nfs file because user A has the dynamic library open
  this .nfs file cannot be removed until user A exits R
  because of this, 00LOCK cannot be removed, and if the
install.packages call is going to install packages after pkg_A, they
fail
   

Yup, I've seen that.  The program "lsof" can be useful to find which process
has the library open.
User A does not need to exit R; it's enough to detach(package:pkg_A);
library(pkg_A);.
 

I have now done more careful experimentation with a colleague so I
have more than 1 user, and my earlier description was wrong.  I can
reliably trigger this 00LOCK problem if a single user does
library(pkg_A) and then in a separate R session does
install.packages(pkg_A).

I cannot reliable trigger it if
1) the library() and install.packages() were done by the same user,
but on different nodes
2) the library() and install.packages() were done by different users, same node
3) the library() and install.packages() were done by different users,
different nodes

I believe I have run into this problem with 00LOCK when I only had one
R session running (the one doing the install.packages), so I am
beginning to believe that what I seem to run into is a race problem.
But I could of course be wrong.

Kasper

__
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] Generate NA of specified type

[Tony Plate]

I just do as.integer(NA), as.numeric(NA), as.character(NA), etc.
-- Tony Plate

On 5/5/2010 11:57 AM, Hadley Wickham wrote:

Hi all,

Is there an existing function that provides the correct type of
missing value for a given vector? e.g.

NAof(1:3) # NA_integer_
NAof(pi) # NA_real_
NAof("a") # NA_character_
NAof(T) # NA

?

Thanks,

Hadley




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] difficulties with setMethod("[" and ...

[Tony Plate]

Jim, yes, I have dealt with that particular challenge that list(...) 
throws an error for a call like f(x,,,) where the empty args match to a 
... formal argument.   Here's some fragments of code that I used to cope 
with this:


# to find the empty anon args, must work with the unevaluated dot args
dot.args.uneval <- match.call(expand.dots=FALSE)$...
if (length(dot.args.uneval))
missing.dot.args <- sapply(dot.args.uneval, function(arg) 
is.symbol(arg) && as.character(arg)=="")

else
missing.dot.args <- logical(0)
...
# Now we can work with evaluated dot args.
# Can't do dot.args <- list(...) because that will
# stop with an error for missing args.
dot.args <- mapply(dot.args.uneval, missing.dot.args, 
FUN=function(arg, m) if (!m) eval(arg) else NULL)


Let me know if you need any further explanation.

Several warnings:
* I was using this code with S3 generics and methods.
* There are quite possibly better ways of detecting empty unevaluated 
arguments than 'is.symbol(arg) && as.character(arg)==""'.
* You'll probably want to be careful that the eval() in the last line is 
using the appropriate environment for your application.


I didn't read your code in detail, so apologies if the above is 
off-the-point, but your verbal description of the problem and the coding 
style and comments in the "[" method for "myExample" triggered my memory.


-- Tony Plate

On 05/17/2010 07:48 PM, James Bullard wrote:

Apologies if I am not understanding something about how things are being
handled when using S4 methods, but I have been unable to find an answer to
my problem for some time now.

Briefly, I am associating the generic '[' with a class which I wrote
(here: myExample). The underlying back-end allows me to read contiguous
slabs, e.g., 1:10, but not c(1, 10). I want to shield the user from this
infelicity, so I grab the slab and then subset in memory. The main problem
is with datasets with dim(.)>  2. In this case, the '...' argument doesn't
seem to be in a reasonable state. When it is indeed missing then it
properly reports that fact, however, when it is not missing it reports
that it is not missing, but then the call to: list(...) throws an argument
is missing exception.

I cannot imagine that this has not occurred before, so I am expecting
someone might be able to point me to some example code. I have attached
some code demonstrating my general problem ((A) and (B) below) as well as
the outline of the sub-selection code. I have to say that coding this has
proven non-trivial and any thoughts on cleaning up the mess are welcome.

As always, thanks for the help.

Jim

require(methods)

setClass('myExample', representation = representation(x = "array"))

myExample<- function(dims = c(1,2)) {
   a<- array(rnorm(prod(dims)))
   dim(a)<- dims
   obj<- new("myExample")
   o...@x<- a
   return(obj)
}

setMethod("dim", "myExample", function(x) return(dim(x...@x)))

functionThatCanOnlyGrabContiguous<- function(x, m, kall) {
   kall$x<- x...@x
   for (i in 1:nrow(m)) {
 kall[[i+2]]<- seq.int(m[i,1], m[i,2])
   }
   print(as.list(kall))
   return(eval(kall))
}

setMethod("[", "myExample", function(x, i, j, ..., drop = TRUE) {
   if (missing(...)){
 print("Missing!")
   }
   e<- list(...)
   m<- matrix(nrow = length(dim(x)), ncol = 2)

   if (missing(i))
 m[1,]<- c(1, dim(x)[1])
   else
 m[1,]<- range(i)

   if (length(dim(x))>  1) {
 if (missing(j))
   m[2,]<- c(1, dim(x)[2])
 else
   m[2,]<- range(j)

 k<- 3
 while (k<= nrow(m)) {
   if (k-2<= length(e))
 m[k,]<- range(e[[k-2]])
   else
 m[k,]<- c(1, dim(x)[k])
   k<- k + 1
 }
   }
   kall<- match.call()
   d<- functionThatCanOnlyGrabContiguous(x, m, kall)

   kall$x<- d
   if (! missing(i)) {
 kall[[3]]<- i - min(i) + 1
   }
   if (! missing(j)) {
 kall[[4]]<- j - min(j) + 1
   } else {
 if (length(dim(x))>  1)
   kall[[4]]<- seq.int(1, dim(x)[2])
   }
   ## XXX: Have to handle remaining dimensions, but since I can't
   ## really get a clean '...' it is on hold.

   eval(kall)
})

## ### 1-D
m<- myExample(10)
m...@x[c(1,5)] == m[c(1, 5)]

## ### 2-D
m<- myExample(c(10, 10))
m...@x[c(1,5), c(1,5)] == m[c(1,5), c(1,5)]
m...@x[c(5, 2),] == m[c(5,2),]

## ### 3-D
m<- myExample(c(1,3,4))

## (A) doesn't work
m...@x[1,1:2,] == m[1,1:2,]

## (B) nor does this for different reasons.
m[1,,1]
m...@x[1,,1]

   

sessionInfo()
 

R version 2.11.0 (2010-04-22)
x86_64-pc-linux-gnu

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5

Re: [Rd] "[" operator and indexing ambiguity

[Tony Plate]

You can find this info using the function nargs().  I've used this with 
S3 classes, and as far as I know it should work with S4 classes too. 
See ?nargs for examples.

-- Tony Plate

Bradley Buchsbaum wrote:
> Hi,
> 
> I am working on writing some S4 classes that represent
> multidimensional (brain) image data.  I would like these classes to
> support standard array indexing. I have been studying the Matrix and
> EBImage (http://www.bioconductor.org/packages/1.9/bioc/html/EBImage.html)
> packages to see how this is done.
> 
> When using objects of the "array" class directly, R distinguishes
> between the calls:
> 
> x[i,,] and x[i]
> 
> with the former returning a 2D array of values and the latter
> returning a single value.  The question I have is whether this same
> behavior can be simulated in classes that do not inherit from the
> "array" class directly? (See below for a snippet from the EBImage
> package which suggests that it cannot).
> 
> My guess is that native array indexing is making use of the
> information provided by the commas, and this is unavailable to user
> implemented class methods?
> 
> thanks,
> 
> Brad Buchsbaum
> 
> 
> 
> # - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> setMethod("[", signature(x = "Image", i = "numeric", j = "missing"),
> function(x, i, j, k, ..., drop) {
> if (missing(k)) {
> warning("using index [int], cannot distinguish from
> [int,,ANY], use [int,1:dim(x)[2],ANY] otherwise")
> tmp = [EMAIL PROTECTED], drop = FALSE]
> }
> else {
> tmp = [EMAIL PROTECTED], , k, drop = FALSE]
> }
> ...
> }
> 
> __
> 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] bug in partial matching of attribute names

[Tony Plate]

There looks to be a bug in do_attr() (src/main/attrib.c): incorrect 
partial matches of attribute names can be returned when there are an odd 
number of partial matches.

E.g.:

 > x <- c(a=1,b=2)
 > attr(x, "abcdef") <- 99
 > attr(x, "ab")
[1] 99
 > attr(x, "abc") <- 100
 > attr(x, "ab") # correctly returns NULL because of ambig partial match
NULL
 > attr(x, "abcd") <- 101
 > attr(x, "ab") # incorrectly returns non-NULL for ambig partial match
[1] 101
 > names(attributes(x))
[1] "names"  "abcdef" "abc""abcd"
 >

The problem in do_attr() looks to be that after match is set to 
PARTIAL2, it can be set back to PARTIAL again.  I think a simple fix is 
to add a "break" in this block in do_attr():

 else if (match == PARTIAL) {
/* this match is partial and we already have a partial match,
   so the query is ambiguous and we return R_NilValue */
match = PARTIAL2;
break; /* < ADD BREAK HERE */
 } else {

However, if this is indeed a bug, would this be a good opportunity to 
get rid of partial matching on attribute names -- it was broken anyway 
-- so toss it out? :-)  Does anyone depend on partial matching for 
attribute names?  My view is that it's one of those things like partial 
matching of list and vector element names that seemed like a good idea 
at first, but turns out to be more trouble than it's worth.

On a related topic, partial matching does not seem to work for the 
"names" attribute (which I would regard as a good thing :-).  However, 
I'm puzzled why it doesn't work, because the code in do_attr() seems to 
try hard to make it work.  Can anybody explain why?

E.g.:
 > attr(x, "names")
[1] "a" "b"
 > attr(x, "nam")
NULL

 > sessionInfo()
R version 2.4.1 (2006-12-18)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods"
[7] "base"
 >

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] question on docs for delayedAssign and substitute

[Tony Plate]

The help files for delayedAssign and substitute both say that 
substitute() can be used to see the expression associated with a 
promise.  However, I can't see how to do that.  When I try the example 
in help file for delayedAssign I don't see substitute() extracting the 
promise, e.g.:

 > msg <- "old"
 > delayedAssign("x", msg)
 > msg <- "new!"
 > substitute(x) #- I would expect to see 'msg' here
x
 > x #- new!
[1] "new!"
 > substitute(x)
x
 >

Has this functionality been removed, and the docs not updated?  Or am I 
missing something?

-- Tony Plate

 > sessionInfo()
R version 2.4.1 (2006-12-18)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods"
[7] "base"

other attached packages:
g.data
  "1.6"
 >

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] bug in partial matching of attribute names

[Tony Plate]

Ok, thanks for the news of a fix in progress.

On the topic of the "names" attribute being treated specially, I wonder 
if the do_attr() function might treat it a little too specially.  As far 
as I can tell, the loop in the first large block code in do_attr() 
(attrib.c), which begins

 /* try to find a match among the attributes list */
 for (alist = ATTRIB(s); alist != R_NilValue; alist = CDR(alist)) {

will find a full or partial match for a "names" attribute (at least for 
ordinary lists and vectors).

Then the large block of code after that, beginning:

 /* unless a full match has been found, check for a "names" attribute */
 if (match != FULL && ! strncmp(CHAR(PRINTNAME(R_NamesSymbol)), str, 
n)) {

seems unnecessary because a names attribute has already been checked 
for.  In the case of a partial match on the "names" attribute this code 
will behave as though there is an ambiguous partial match, and 
(incorrectly) return Nil.  Is this second block of code specific to the 
"names" attribute possibly a hangover from an earlier day when the first 
loop didn't detect a "names" attribute?  Or am I missing something?  Are 
there some other objects for which the first loop doesn't include a 
"names" attribute?

-- Tony Plate

Prof Brian Ripley wrote:
> It happens that I was looking at this yesterday (in connection with 
> encodings on CHARSXPs) and have a fix in testing across CRAN right now.
> 
> As for "names", as you will know from reading 'R Internals' the names 
> can be stored in more than one place, which is why it has to be treated 
> specially.
> 
> On Mon, 12 Feb 2007, Tony Plate wrote:
> 
>> There looks to be a bug in do_attr() (src/main/attrib.c): incorrect
>> partial matches of attribute names can be returned when there are an odd
>> number of partial matches.
>>
>> E.g.:
>>
>> > x <- c(a=1,b=2)
>> > attr(x, "abcdef") <- 99
>> > attr(x, "ab")
>> [1] 99
>> > attr(x, "abc") <- 100
>> > attr(x, "ab") # correctly returns NULL because of ambig partial match
>> NULL
>> > attr(x, "abcd") <- 101
>> > attr(x, "ab") # incorrectly returns non-NULL for ambig partial match
>> [1] 101
>> > names(attributes(x))
>> [1] "names"  "abcdef" "abc""abcd"
>> >
>>
>> The problem in do_attr() looks to be that after match is set to
>> PARTIAL2, it can be set back to PARTIAL again.  I think a simple fix is
>> to add a "break" in this block in do_attr():
>>
>> else if (match == PARTIAL) {
>> /* this match is partial and we already have a partial match,
>>so the query is ambiguous and we return R_NilValue */
>> match = PARTIAL2;
>> break; /* < ADD BREAK HERE */
>> } else {
>>
>> However, if this is indeed a bug, would this be a good opportunity to
>> get rid of partial matching on attribute names -- it was broken anyway
>> -- so toss it out? :-)  Does anyone depend on partial matching for
>> attribute names?  My view is that it's one of those things like partial
>> matching of list and vector element names that seemed like a good idea
>> at first, but turns out to be more trouble than it's worth.
>>
>> On a related topic, partial matching does not seem to work for the
>> "names" attribute (which I would regard as a good thing :-).  However,
>> I'm puzzled why it doesn't work, because the code in do_attr() seems to
>> try hard to make it work.  Can anybody explain why?
>>
>> E.g.:
>> > attr(x, "names")
>> [1] "a" "b"
>> > attr(x, "nam")
>> NULL
>>
>> > sessionInfo()
>> R version 2.4.1 (2006-12-18)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MONETARY=English_United
>> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>>
>> attached base packages:
>> [1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods"
>> [7] "base"
>> >
>>
>> -- Tony Plate
>>
>> __
>> 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] bug in partial matching of attribute names

[Tony Plate]

Prof Brian Ripley wrote:
> On Tue, 13 Feb 2007, Tony Plate wrote:
> 
>> Ok, thanks for the news of a fix in progress.
> 
> 
> BTW, your suggested fix is incorrect.  Consider having an exact match 
> after two partial matches in the list of attributes.
oops.  yes.

> 
>> On the topic of the "names" attribute being treated specially, I 
>> wonder if the do_attr() function might treat it a little too 
>> specially.  As far as I can tell, the loop in the first large block 
>> code in do_attr() (attrib.c), which begins
>>
>>/* try to find a match among the attributes list */
>>for (alist = ATTRIB(s); alist != R_NilValue; alist = CDR(alist)) {
>>
>> will find a full or partial match for a "names" attribute (at least 
>> for ordinary lists and vectors).
>>
>> Then the large block of code after that, beginning:
>>
>>/* unless a full match has been found, check for a "names" 
>> attribute */
>>if (match != FULL && ! strncmp(CHAR(PRINTNAME(R_NamesSymbol)), str, 
>> n)) {
>>
>> seems unnecessary because a names attribute has already been checked 
>> for. In the case of a partial match on the "names" attribute this code 
>> will behave as though there is an ambiguous partial match, and 
>> (incorrectly) return Nil.  Is this second block of code specific to 
>> the "names" attribute possibly a hangover from an earlier day when the 
>> first loop didn't detect a "names" attribute?  Or am I missing 
>> something?  Are there some other objects for which the first loop 
>> doesn't include a "names" attribute?
> 
> 
> Yes: I pointed you at the 'R internals' manual, but this is also on the 
> help page.  1D arrays and pairlists have names stored elsewhere.  It 
> needs to be changed to be
> 
> -   else if (match == PARTIAL) {
> +   else if (match == PARTIAL && strcmp(CHAR(PRINTNAME(tag)), 
> "names")) {

Wouldn't it be equivalent (but clearer & a minute fraction more 
computationally efficient) to put that test 
'strcmp(CHAR(PRINTNAME(tag)), "names")' right at the start of that 
block, i.e., as an additional condition in

 if (match != FULL && ! strncmp(CHAR(PRINTNAME(R_NamesSymbol)), str, 
n)) {

?

-- Tony Plate

> 
> 
>> -- Tony Plate
>>
>> Prof Brian Ripley wrote:
>>
>>> It happens that I was looking at this yesterday (in connection with 
>>> encodings on CHARSXPs) and have a fix in testing across CRAN right now.
>>>
>>> As for "names", as you will know from reading 'R Internals' the names 
>>> can be stored in more than one place, which is why it has to be 
>>> treated specially.
>>>
>>> On Mon, 12 Feb 2007, Tony Plate wrote:
>>>
>>>> There looks to be a bug in do_attr() (src/main/attrib.c): incorrect
>>>> partial matches of attribute names can be returned when there are an 
>>>> odd
>>>> number of partial matches.
>>>>
>>>> E.g.:
>>>>
>>>> > x <- c(a=1,b=2)
>>>> > attr(x, "abcdef") <- 99
>>>> > attr(x, "ab")
>>>> [1] 99
>>>> > attr(x, "abc") <- 100
>>>> > attr(x, "ab") # correctly returns NULL because of ambig partial match
>>>> NULL
>>>> > attr(x, "abcd") <- 101
>>>> > attr(x, "ab") # incorrectly returns non-NULL for ambig partial match
>>>> [1] 101
>>>> > names(attributes(x))
>>>> [1] "names"  "abcdef" "abc""abcd"
>>>> >
>>>>
>>>> The problem in do_attr() looks to be that after match is set to
>>>> PARTIAL2, it can be set back to PARTIAL again.  I think a simple fix is
>>>> to add a "break" in this block in do_attr():
>>>>
>>>> else if (match == PARTIAL) {
>>>> /* this match is partial and we already have a partial match,
>>>>so the query is ambiguous and we return R_NilValue */
>>>> match = PARTIAL2;
>>>> break; /* < ADD BREAK HERE */
>>>> } else {
>>>>
>>>> However, if this is indeed a bug, would this be a good opportunity to
>>>> get rid of partial matching on attribute names -- it was broken anyway
>>>> -- so toss it out? :-)  Does anyone depend on partial matching for
>>>> attribute names

[Rd] proposal to allow just transcript files (output only) in the 'tests' directory

[Tony Plate]

Currently, as far as I can see, both input and output fles must be 
supplied in the 'tests' directory (the input in a '.R' file, and the 
output in a corresponding '.Rout.save' file.)  Often, the '.R' file is 
redundant, as it could be reconstructed by simply stripping the commands 
out of the '.Rout.save' file.  E.g., the command
$ sed -n -e 's/^[>+] //p' ./src/library/stats/tests/nls.Rout.save
produces the same R commands as in ./src/library/stats/tests/nls.R

If I've missed something, and this is already supported, my apologies, & 
please let me know.

If indeed this facility is not present, would anyone from the R core 
group consider an addition to allow '.Rt' (or '.Rt.save') files in the 
'tests' directory?  These would by just like the '.Rout.save' files, 
except that no corresponding '.R' file would be required -- the R 
commands would be extracted from them by simple line processing.  Of 
course, '.R' and '.Rout.save' files could still be used where necessary 
or preferred.

The primary advantage of this change would be to make it easier to add 
and maintain tests -- only one file would need to be created or changed, 
and no redundant information would be required.  My view is that tests 
should be as easy as possible to create and maintain, and the current 
system adds a small amount of unnecessary difficulty.

If such an addition would be considered, I would be happy to supply 
patches to implement it (and test them in a build under Windows & 
Linux).  I have tested a prototype, and it seems pretty simple to add 
this: as far as I can see, small changes are needed in three files:

./share/make/tests.mk
./src/gnuwin32/fixed/share/tests.mk
./bin/check

Please respond with 
comments/suggestions/corrections/pointing-out-of-gotchas/etc!

thanks,

Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] checking existence of active bindings

[Tony Plate]

Is there any way to check whether an active binding exists without 
actually calling the active binding?  I'd like to be able to do 
something like exists("x", ...) and know whether "x" exists without 
actually fetching its value if it is an active binding (because it could 
consume significant resources to fetch the value).

The documentation for exists() doesn't really say whether or not the 
value is actually retrieved.  I guess that ?exists was written before 
the (experimental) active binding code, but still it would be nice if 
exists("x", mode="any") didn't call an active binding for "x".

Here's an example showing that exists() does result in the active 
binding being called:

 > fx <- function(v) {
+ if (missing(v))
+ cat("getting x1\n")
+ else {
+ cat("setting x1\n")
+ assign("x1", v, envir=globalenv())
+ }
+ get("x1", envir=globalenv())
+ }
 > makeActiveBinding("x", fx, globalenv())
NULL
 > x1 <- 3
 > x
getting x1
[1] 3
 > exists("x", inherits=FALSE)
getting x1
[1] TRUE
 > sessionInfo()
R version 2.4.1 (2006-12-18)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252

attached base packages:
[1] "stats" "graphics"  "grDevices" "utils" "datasets" 
"methods"   "base"

other attached packages:
   abind  g.data   chron   fCalendar fEcofin
 "1.1-0"   "1.6""2.3-10" "240.10068" "240.10067"
 >


 From looking at the source, the exists() calls function 
findVarInFrame3() (envir.c) with doGet=FALSE.  The comments for the 
argument doGet on findVarInFrame3() say:

   The final argument is usually TRUE and indicates whether the
   lookup is being done in order to get the value (TRUE) or
   simply to check whether there is a value bound to the specified
   symbol in this frame (FALSE).  This is used for get() and exists().

Nonetheless, the value is actually retrieved when doGet=FALSE (at least 
for ordinary environments, such as the global environment).  (I'm not 
trying to claim that this behavior contradicts the documentation, but 
it's not what I expected from reading the documentation.)

The only ways I can see to check in pure R if an active binding exists 
without calling the binding are things like
 > identical(TRUE, try(bindingIsActive("x", globalenv()), silent=TRUE))
 > is.element("x", objects(all=T, envir=globalenv()))
but I was hoping to just be able to use exists().

Was this interaction of exists() with active bindings intended, or did 
it just arise by accident and might be subject to future improvement?

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Developer work cycle

[Tony Plate]

I tried to summarize some of the very useful tips in this discussion in 
the R Wiki at 
http://wiki.r-project.org/rwiki/doku.php?id=developers:workcycle

If you feel I used your contribution inappropriately, please let me know 
and I'll remove it.

Anyone, please feel free to improve it!

-- Tony Plate


[EMAIL PROTECTED] wrote:
> Couple of quick points:
> 
> FYI1: the 'mtrace' function in the 'debug' package does let you trace hidden 
> S3 methods (though it lacks the edit= argument).
> 
> FYI2: In my own alpha-version of 'mvbutils', I am able to do live edits of 
> code in (selected) installed packages, including adding & deleting functions 
> from the namespace, and also to do a quick patch of the installed library 
> from inside R (rather than requiring re-installation) so that the modified 
> version is loaded next time I use 'library'. I only need to re-build the 
> package with rcmd when I want to update the helpfiles. My plan is to release 
> the new 'mvbutils' later this year-- time permitting.
> 
> Mark
> 
> Mark Bravington
> CSIRO Mathematical & Information Sciences
> Marine Laboratory
> Castray Esplanade
> Hobart 7001
> TAS
> 
> ph (+61) 3 6232 5118
> fax (+61) 3 6232 5012
> mob (+61) 438 315 623
>  
> 
>> -Original Message-
>> From: [EMAIL PROTECTED] 
>> [mailto:[EMAIL PROTECTED] On Behalf Of John Chambers
>> Sent: Friday, 30 March 2007 10:34 AM
>> To: Douglas Bates
>> Cc: "José Luis Aznarte M."; r-devel@r-project.org
>> Subject: Re: [Rd] Developer work cycle
>>
>> Douglas Bates wrote:
>>> On 3/26/07, "José Luis Aznarte M." <[EMAIL PROTECTED]> wrote:
>>>   
>>>> Hi! I've been browsing through the last months' archive and I 
>>>> can't find an answer to my question, so here it is (let's 
>> hope it's 
>>>> not too
>>>> obvious):
>>>> I'm working on extensions of an R library, and I would be very 
>>>> surprised if everyone developing R packages is doing the 
>> following, as I do:
>>>> 1.- Write down a modification of an R file
>>>> 2.- Exit the current R session
>>>> 3.- Install the package as root (sudo R CMD INSTALL...)
>>>> 4.- Launch a new R session
>>>> 5.- Test the change, if it does not work, go back 
>> to 1 or debug.
>>>> 6.- Finish.
>>>>
>>>> Is this the proper (but quite awkward) way to proceed 
>> or there is 
>>>> an alternative to skip steps 2 to 4? I'm using emacs with 
>> ESS under linux.
>>>> 
>>> John Chambers has provided an alternative approach of using
>>>
>>> trace(fname, edit = TRUE)
>>>
>>> where fname is the name of your function.  (Make sure that 
>> the server 
>>> for emacsclient has been started in your emacs session with M-x
>>> server-start.)  This opens an emacs buffer containing the 
>> source for 
>>> the function which you can then edit.  After writing the file and 
>>> closing the client (C-x #) your ESS session has the new definition 
>>> installed in the package's namespace.
>>>
>>> This will work even for objects hidden in the namespace.  
>> The argument 
>>> "signature" allows you to edit S4 methods on the fly like 
>> this.  In my 
>>> experience you cannot edit registered S3 methods like this 
>> but it may 
>>> be that I am just not using trace correctly.
>>>   
>> Indeed, trace() does not currently work for registered S3 
>> methods, with or without the edit=TRUE argument.
>>
>> There is a fix, just committed to r-devel, which should be in 
>> the final 2.5.0.
>>> Of course you must copy the modified version of the source code to 
>>> your package sources when you are done.
>>>
>>> As others have indicated, it is a good practice to install 
>> development 
>>> versions of packages in a private library so you do not need to use 
>>> sudo or worry about messing up system-wide directories.
>>>
>>> __
>>> 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
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] list/matrix chimera

[Tony Plate]

Aren't you just seeing the effect of drop=TRUE? (at least with the 
examples you give below -- they all pick out a submatrix with extent one 
on some dimension)

AFAICT, matrices with a list as the underlying data work properly, e.g.:

 > vv <- array(as.list(1:12), 3:4)
 > vv
  [,1] [,2] [,3] [,4]
[1,] 14710
[2,] 25811
[3,] 36912
 > vv[1:2,]
  [,1] [,2] [,3] [,4]
[1,] 14710
[2,] 25811
 > vv[1,,drop=FALSE]
  [,1] [,2] [,3] [,4]
[1,] 14710
 >

It can actually be useful sometimes to have a matrix (or array) of 
non-atomic objects -- wouldn't your proposed change remove (or at least 
damage) that functionality?

-- Tony Plate

Seth Falcon wrote:
> Hi all,
> 
> If dimensions are added to a list, it will become a matrix-like hybrid
> that calls itself a matrix, but returns lists for subset operations.
> 
> This was brought to my attention by a user that encountered such an
> object and was quite confused by its behavior.  Although I have not
> found the code that created the object yet, I believe that code is
> simply incorrect.  Nevertheless, I wonder if R_data_class in attrib.c
> should be a bit more discriminating and only return matrix or array
> for atomic vectors.  Perhaps something like this:
> 
> --- a/src/main/attrib.c
> +++ b/src/main/attrib.c
> @@ -536,7 +536,7 @@ SEXP R_data_class(SEXP obj, Rboolean singleString)
>  if(n == 0) {
> SEXP dim = getAttrib(obj, R_DimSymbol);
> int nd = length(dim);
> -   if(nd > 0) {
> +   if(nd > 0 && isVectorAtomic(obj)) {
> if(nd == 2)
> klass = mkChar("matrix");
> else
> 
> Here is an example that illustrates:
> 
> vv <- as.list(1:24)
> dim(vv) <- c(6, 4)
> vv
>  [,1] [,2] [,3] [,4]
> [1,] 1713   19  
> [2,] 2814   20  
> [3,] 3915   21  
> [4,] 410   16   22  
> [5,] 511   17   23  
> [6,] 612   18   24  
> 
> class(vv)
> [1] "matrix"
> 
> typeof(vv)
> [1] "list"
> 
> vv[1, 1]
> [[1]]
> [1] 1
> 
> vv[1, ]
> [[1]]
> [1] 1
> 
> [[2]]
> [1] 7
> 
> [[3]]
> [1] 13
> 
> [[4]]
> [1] 19
> 
> 
> + seth
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] list/matrix chimera

[Tony Plate]

hadley wickham wrote:
> On 4/10/07, Tony Plate <[EMAIL PROTECTED]> wrote:
>> Aren't you just seeing the effect of drop=TRUE? (at least with the
>> examples you give below -- they all pick out a submatrix with extent one
>> on some dimension)
>>
>> AFAICT, matrices with a list as the underlying data work properly, e.g.:
>>
>>  > vv <- array(as.list(1:12), 3:4)
>>  > vv
>>   [,1] [,2] [,3] [,4]
>> [1,] 14710
>> [2,] 25811
>> [3,] 36912
>>  > vv[1:2,]
>>   [,1] [,2] [,3] [,4]
>> [1,] 14710
>> [2,] 25811
>>  > vv[1,,drop=FALSE]
>>   [,1] [,2] [,3] [,4]
>> [1,] 14710
>>  >
>>
>> It can actually be useful sometimes to have a matrix (or array) of
>> non-atomic objects -- wouldn't your proposed change remove (or at least
>> damage) that functionality?
> 
> I use this functionality a lot in the reshape package.  I would hate
> to see it go!
> 
> It would be nice to have some way to remove the [[1]] from vv[1, 2][[1]] 
> though.
> 
> Hadley
> 

Doesn't vv[[1,2]] do that?

-- Tony

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] accessing hidden functions in testing code

[Tony Plate]

I'd like to be able to access unexported functions in the testing code 
for a package with a namespace.  I know that one way to do this is to 
use the ":::" operator, but I'd prefer to avoid cluttering up my testing 
code with lots of repetitions of "myPackageName:::".

One way I found to do this was to attach() the namespace of the package, 
e.g., using the following:

pkg <- "myPackageName"
library(package=pkg, character.only=TRUE)
## --- Load the name space to allow testing of private functions ---
if (is.element(pkg, loadedNamespaces()))
 attach(loadNamespace(pkg), name=paste("namespace", pkg, sep=":"), 
pos=3)


Are there any pitfalls that I will find if I continue with this 
approach?  Or is there another better way?

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] how to control which version of a package library() installs?

[Tony Plate]

library() seems to remember the location of a package when I give it a 
lib.loc, and then use that version thereafter, even if I don't supply 
lib.loc again.  Is there any way I can load different versions of a 
package in one R session? -- I don't seem to able to simply detach the 
package and then load a different version from a different library location.

$ R
[...startup info...]
 > # only version we currently know about is in the standard library
 > .find.package("ExamplePackage")
[1] "c:/R/R-2.4.1/library/ExamplePackage"
 > # load a version from a different library e:/devinst
 > library(ExamplePackage, lib.loc="e:/devinst")
 > # and check we've got the right version ... yes
 > system.file(package="ExamplePackage")
[1] "e:/devinst/ExamplePackage"
 > .find.package("ExamplePackage")
[1] "e:/devinst/ExamplePackage"
 > detach(2)
 >
 > # Now I'd like to load the version in the standard library.
 > # .find.package() finds the version I want
 > .find.package("ExamplePackage")
[1] "c:/R/R-2.4.1/library/ExamplePackage"
 > # but library() loads the same version it did before, even
 > # though I don't supply lib.loc, and .libPaths is untouched.
 > library(ExamplePackage)
 > system.file(package="ExamplePackage")
[1] "e:/devinst/ExamplePackage"
 > .find.package("ExamplePackage")
[1] "e:/devinst/ExamplePackage"
 > .libPaths()
[1] "c:/R/R-2.4.1/library"
 > sessionInfo()
R version 2.4.1 (2006-12-18)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MON
ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United 
States.1252


attached base packages:
[1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods"
[7] "base"

other attached packages:
ExamplePackage
  "1.0"
 >

Am I doing something wrong here?  I can't find any mention of 
persistence of package location in ?library.

thanks for any help or suggestions,

Tony Plate

__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to control which version of a package library() installs?

[Tony Plate]

Thank you!  I had not realized that the name space remained loaded. 
When I did unloadNamespace("ExamplePackage") after the detach() I got 
what I wanted.

Maybe the following sentence might be a useful addition to the "Details" 
or "Notes" section of the help page for detach?:
   To detach() and reattach() a package you will probably need to use 
unloadNamespace("somePackage") after detach("package:somePackage")

-- Tony Plate


Prof Brian Ripley wrote:
> On Fri, 13 Apr 2007, Tony Plate wrote:
> 
>> library() seems to remember the location of a package when I give it a
>> lib.loc, and then use that version thereafter, even if I don't supply
> 
> Not quite: it notices that it is loaded and does not load it again, 
> possibly attaching the exports of a still-loaded namespace.
> 
>> lib.loc again.  Is there any way I can load different versions of a
>> package in one R session? -- I don't seem to able to simply detach the
>> package and then load a different version from a different library 
>> location.
> 
> Without the output of search(), searchpath() and loadedNamespace() we 
> cannot know what happened here.  But here is an example of my own
> 
>> library(Matrix, lib.loc="~/R/test26")
> Loading required package: lattice
>> searchpaths()
>  [1] ".GlobalEnv"
>  [2] "/data/gannet/ripley/R/test26/Matrix"
>  ...
>> detach(2)
>> search()
>  [1] ".GlobalEnv""package:lattice"   "package:stats"
>  [4] "package:graphics"  "package:grDevices" "package:utils"
>  [7] "package:datasets"  "package:methods"   "Autoloads"
> [10] "package:base"
>> library(Matrix, lib.loc="~/R/test-library")
>> searchpaths()
>  [1] ".GlobalEnv"
>  [2] "/data/gannet/ripley/R/test26/Matrix"
>  ...
> 
> The point is that the namespace Matrix is still loaded.
> 
>> detach(2)
>> unloadNamespace("Matrix")
>> library(Matrix, lib.loc="~/R/test-library")
>> searchpaths()
>  [1] ".GlobalEnv"
>  [2] "/data/gannet/ripley/R/test-library/Matrix"
> 
> Might your example be similar?
> 
> 
>> $ R
>> [...startup info...]
>> > # only version we currently know about is in the standard library
>> > .find.package("ExamplePackage")
>> [1] "c:/R/R-2.4.1/library/ExamplePackage"
>> > # load a version from a different library e:/devinst
>> > library(ExamplePackage, lib.loc="e:/devinst")
>> > # and check we've got the right version ... yes
>> > system.file(package="ExamplePackage")
>> [1] "e:/devinst/ExamplePackage"
>> > .find.package("ExamplePackage")
>> [1] "e:/devinst/ExamplePackage"
>> > detach(2)
>> >
>> > # Now I'd like to load the version in the standard library.
>> > # .find.package() finds the version I want
>> > .find.package("ExamplePackage")
>> [1] "c:/R/R-2.4.1/library/ExamplePackage"
>> > # but library() loads the same version it did before, even
>> > # though I don't supply lib.loc, and .libPaths is untouched.
>> > library(ExamplePackage)
>> > system.file(package="ExamplePackage")
>> [1] "e:/devinst/ExamplePackage"
>> > .find.package("ExamplePackage")
>> [1] "e:/devinst/ExamplePackage"
>> > .libPaths()
>> [1] "c:/R/R-2.4.1/library"
>> > sessionInfo()
>> R version 2.4.1 (2006-12-18)
>> i386-pc-mingw32
>>
>> locale:
>> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
>> States.1252;LC_MON
>> ETARY=English_United States.1252;LC_NUMERIC=C;LC_TIME=English_United
>> States.1252
>>
>>
>> attached base packages:
>> [1] "stats" "graphics"  "grDevices" "utils" "datasets"  "methods"
>> [7] "base"
>>
>> other attached packages:
>> ExamplePackage
>>  "1.0"
>> >
>>
>> Am I doing something wrong here?  I can't find any mention of
>> persistence of package location in ?library.
>>
>> thanks for any help or suggestions,
>>
>> Tony Plate
>>
>> __
>> [EMAIL PROTECTED] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>

__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to control which version of a package library() installs?

[Tony Plate]

Tony Plate wrote:
> [snip]
 >
> Maybe the following sentence might be a useful addition to the "Details" 
> or "Notes" section of the help page for detach?:
>To detach() and reattach() a package you will probably need to use 
> unloadNamespace("somePackage") after detach("package:somePackage")
> 

Better: "If you want to detach() and reattach() a package to get a 
different version of it, you will probably need to use 
unloadNamespace("somePackage") after detach("package:somePackage")"

-- Tony Plate

__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] how to control which version of a package library() installs?

[Tony Plate]

Prof Brian Ripley wrote:
> On Fri, 13 Apr 2007, Tony Plate wrote:
> 
>> Thank you!  I had not realized that the name space remained loaded. 
>> When I did unloadNamespace("ExamplePackage") after the detach() I got 
>> what I wanted.
>>
>> Maybe the following sentence might be a useful addition to the 
>> "Details" or "Notes" section of the help page for detach?:
>>  To detach() and reattach() a package you will probably need to use 
>> unloadNamespace("somePackage") after detach("package:somePackage")
> 
> We should try to explain this, but there is another level of complexity.
> If a package has compiled code, unloading the namespace is unlikely to 
> unload the DLL (it would need to be done explicitly in .onUnload).
> And even then, as I understand it there are OSes on which you cannot 
> really unload DLLs, and certainly cannot load another DLL of the same 
> name into the process: you get the previously loaded one.
> 
> Given all the issues, I always work on the assumption that re-loading a 
> package into a R session is not going to do what I intend.

Ok, but will it work for packages with pure R code? (disregarding things 
a package might do in its load hooks).  If so, then how about:

To detach() and reattach() a package in order to get a different version 
of it, it will be necessary to do unloadNamespace("somePackage") after 
detach("package:somePackage").  However, this is very likely to be 
problematic for packages with compiled code because some OSes do not 
support unloading DLLs or loading another DLL of the same name.

Or are there yet other issues?

-- Tony Plate

> 
>>
>> -- Tony Plate
>>
>>
>> Prof Brian Ripley wrote:
>>> On Fri, 13 Apr 2007, Tony Plate wrote:
>>>
>>>> library() seems to remember the location of a package when I give it a
>>>> lib.loc, and then use that version thereafter, even if I don't supply
>>>
>>> Not quite: it notices that it is loaded and does not load it again, 
>>> possibly attaching the exports of a still-loaded namespace.
>>>
>>>> lib.loc again.  Is there any way I can load different versions of a
>>>> package in one R session? -- I don't seem to able to simply detach the
>>>> package and then load a different version from a different library 
>>>> location.
>>>
>>> Without the output of search(), searchpath() and loadedNamespace() we 
>>> cannot know what happened here.  But here is an example of my own
>>>
>>>> library(Matrix, lib.loc="~/R/test26")
>>> Loading required package: lattice
>>>> searchpaths()
>>>  [1] ".GlobalEnv"
>>>  [2] "/data/gannet/ripley/R/test26/Matrix"
>>>  ...
>>>> detach(2)
>>>> search()
>>>  [1] ".GlobalEnv""package:lattice"   "package:stats"
>>>  [4] "package:graphics"  "package:grDevices" "package:utils"
>>>  [7] "package:datasets"  "package:methods"   "Autoloads"
>>> [10] "package:base"
>>>> library(Matrix, lib.loc="~/R/test-library")
>>>> searchpaths()
>>>  [1] ".GlobalEnv"
>>>  [2] "/data/gannet/ripley/R/test26/Matrix"
>>>  ...
>>>
>>> The point is that the namespace Matrix is still loaded.
>>>
>>>> detach(2)
>>>> unloadNamespace("Matrix")
>>>> library(Matrix, lib.loc="~/R/test-library")
>>>> searchpaths()
>>>  [1] ".GlobalEnv"
>>>  [2] "/data/gannet/ripley/R/test-library/Matrix"
>>>
>>> Might your example be similar?
>>>
>>>
>>>> $ R
>>>> [...startup info...]
>>>> > # only version we currently know about is in the standard library
>>>> > .find.package("ExamplePackage")
>>>> [1] "c:/R/R-2.4.1/library/ExamplePackage"
>>>> > # load a version from a different library e:/devinst
>>>> > library(ExamplePackage, lib.loc="e:/devinst")
>>>> > # and check we've got the right version ... yes
>>>> > system.file(package="ExamplePackage")
>>>> [1] "e:/devinst/ExamplePackage"
>>>> > .find.package("ExamplePackage")
>>>> [1] "e:/devinst/ExamplePackage"
>>>> > detach(2)
>>>> >
>>>> > # Now I'd like to load the 

[Rd] typo in R-exts

[Tony Plate]

There looks to be a typo in the R-exts manual:

The whose @file{tests} is copied to the check area, ...
 ^

I'm not sure what was intended here, so I can't suggest a fix.

(from https://svn.r-project.org/R/trunk/doc/manual/R-exts.texi)

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] use of .Rout.save files in the 'tests' directory of a package

[Tony Plate]

Even though all files in the 'tests' directory are copied to the 
installation directory and tests are run there, the current makefiles 
that runs the tests (share/make/{tests,wintests}.mk seem to go to some 
trouble to refer to the .Rout.save files in the original 'tests' 
directory. (E.g., in the line "@if test -f $(srcdir)/[EMAIL PROTECTED]; then" 
in 
share/make/tests.mk.)  This means that .Rout.save files created during 
the testing process (either by .Rin files or via 'make') are not seen. 
I'm using R-2.5.0 (beta) under Windows and Linux, and AFAICT, this is 
the same under both systems.

Is there some good reason that .Rout.save files from the source 'tests' 
directory are used rather than the ones in the fresh copy of the 'tests' 
directory?  If this is some sort of historical legacy, could this be 
changed so that the testing always uses the copies of the files in fresh 
copy of the 'tests' directory?  (In cases where they are present in the 
source directory, they should be identical, AFAICS.)

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] typo in R-exts

[Tony Plate]

The actual behavior, as far as I can make out, is that all the files in 
the 'tests' directory are copied, but not any subdirectories (which I 
personally would have found useful).

So, saying the "whole directory" is probably not accurate.

-- Tony Plate

Peter Dalgaard wrote:
> Tony Plate wrote:
>> There looks to be a typo in the R-exts manual:
>>
>> The whose @file{tests} is copied to the check area, ...
>>  ^
>>
>> I'm not sure what was intended here, so I can't suggest a fix.
>>   
> 'svn blame' tells me that this was Brian's addition in rev.35362. There 
> is no previous version to help with guessing the intention. One 
> possibility is that "The whose" should be "The directory", or maybe "The 
> whole directory".
>> (from https://svn.r-project.org/R/trunk/doc/manual/R-exts.texi)
>>
>> -- Tony Plate
>>
>> __
>> 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] ifelse behaviour

[Tony Plate]

A simpler version of your "puzzling call to ifelse" is

ifelse(FALSE, character(0), integer(0))

The most obvious way to satisfy the requirements stated in the 
documentation is to extend integer(0) to length 1 by creating an NA 
value, and that's what you get as a return value (here the 'test' 
argument has length 1, and the 'no' argument has length 0).

-- Tony Plate


[EMAIL PROTECTED] wrote:
> Hi!
>
> I'm puzzled by the return value of ifelse
>
> consider
>
> x<-integer(0)
> ifelse(is(x, "character"), paste(x), x)
> [1] NA
>
> whereas
> if (is(x, "character")) return(paste(x)) else x
> [1] integer(0)
>
> or
> x<-integer(1)
> ifelse(is(x, "character"), paste(x), x)
> [1] 0
>
> work as I had anticipated. Is this correct behaviour?
>
> Regards,
>
>Matthias
>
>
>  >sessionInfo()
> R version 2.5.0 (2007-04-23)
> i686-pc-linux-gnu
>
> locale:
> C
>
> attached base packages:
> [1] "stats" "graphics"  "grDevices" "datasets"  "utils" "methods"
> [7] "base"
>
> other attached packages:
> rcompletionrcompgen
>  "0.1-2""0.1-10"
>
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] system() in packages

[Tony Plate]

With cygwin bash installed under Windows, one can use pipes in system(), 
e.g., like this:

R 2.5.0 under Windows XP:
 > system("echo foo | sed s/foo/bar/") # this doesn't work under windows
foo | sed s/foo/bar/
 > # but using 'bash -c' does:
 > system("bash -c \"echo foo | sed s/foo/bar/\"")
bar
 > # and some use of quotes within the command actually works!
 > system("bash -c \"echo foo | sed 's/foo/bar rrr/'\"")
bar rrr
 >

[Beware: complex quoting inside the -c command can be difficult to get 
right.]

-- Tony Plate


Prof Brian Ripley wrote:
> The first comment is that will only work on Unix-alikes, since '|' needs a 
> shell.
> 
> So, if this is on a Unix-alike you need to establish if the program is in 
> the path at run time and cache the result.  I have no idea if this would 
> actually work, but for example system('gp --version') might provide a 
> suitable test.
> 
> On Fri, 27 Apr 2007, Robin Hankin wrote:
> 
>> Hello
>>
>> Quite often I need higher precision, or larger numbers,
>>  than IEEE double precision allows.  One strategy I sometimes
>> use is to use system() to call pari/gp, which is not constrained by
>> IEEE.
>>
>> [pari/gp is a GPL high-level mathematical programming language
>> geared towards pure mathematics]
>>
>> Two of my packages contain lines like the following:
>>
>>> system(" echo '1.12^66' | gp -q f",intern=TRUE)
>> [1]
>> "1771.697189476241729649767636564084681203806302318041262248838950177194
>> 116346432205160921568393661760"
>>
>> Note the high precision of the answer.
>>
>> My question is, how to deal with the possibility that pari/gp is not
>> installed?
>>
>> If the system cannot find gp for some reason, I get:
>>
>>> system(" echo '1.12^66' | gp -q f",intern=TRUE)
>> sh: line 1: gp: command not found
>> character(0)
>> What's the recommended way to handle this eventuality gracefully?  The
>> functions that do use pari/gp have "pure" R equivalents (but much
>> slower and less accurate)  so I want users to be able to install the
>> package without pari/gp.
>>
>>
>> --
>> Robin Hankin
>> Uncertainty Analyst
>> National Oceanography Centre, Southampton
>> European Way, Southampton SO14 3ZH, UK
>>  tel  023-8059-7743
>>
>> __
>> 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] bounties

[Tony Plate]

I've wondered about this sort of thing too.  Are there any successful 
models like this for other program languages/systems?

-- Tony Plate

Ben Bolker wrote:
>   Has anyone considered a bounty system for R?
> (i.e., some kind of system whereby users could put
> up money to request particular improvements/bits of
> R code.  These bits of R code need not be incorporated
> into base R unless they're deemed sufficiently useful,
> but they could go (e.g.) on the Wiki)
> 
>   Ben Bolker
> 
> __
> 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] sweep sanity checking?

[Tony Plate]

Just an opinion from an R user: I think it's a sound idea.  I use my own 
version of sweep with a stricter check: it stops if the vector is not 
exactly the right length.

-- Tony Plate

Ben Bolker wrote:
> Ben Bolker  zoo.ufl.edu> writes:
>
>   
>>   What would R-core think of the following 'enhanced'
>> sweep?  
>> 
>
>  (now posted at
> http://wiki.r-project.org/rwiki/doku.php?id=rdoc:base:sweep
> )
>
> It always warns if dim(x)[MARGIN] is
>   
>> not a multiple of length(STATS) {it's very hard indeed
>> for me to think of a situation where you'd actually
>> want this}; if check.margin=TRUE it is a bit stricter,
>> complaining whenever dim(x)[MARGIN] doesn't
>> match length(STATS).
>>
>>   This change seems fairly harmless since it never does anything
>> more than warn; the default for check.margin could
>> be FALSE if you wanted to allow people a bit more rope
>> to hang themselves with ...  (of course this won't prevent
>> you from sweeping the wrong margin of a square matrix,
>> but nothing will).
>>
>>   cheers
>> Ben Bolker
>>
>> 
>
>   Enough time has now passed that I feel justified following up
> on this.  Does anyone have any opinions on it, one way or the other?
>
>   Ben
>
> __
> 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] subcripts on data frames (PR#9885)

[Tony Plate]

The line

worms[rev(order(Worm.density)),] [!duplicated(Vegetation),]

looks suspect to me -- it looks like you are first creating an sorted 
version of the dataframe 'worms', and then subsetting it based on values 
of 'Vegetation' in the original order.  When reordering dataframes I 
would avoid 'attaching' them and I would break the expression into two 
separate expressions, so to be sure the subsetting is referring to the 
appropriate values:

 > worms <- 
read.table("http://www.bio.ic.ac.uk/research/mjcraw/therbook/data/worms.txt";, 
header=T)
 > worms2 <- worms[rev(order(worms$Worm.density)), ]
 > worms2[!duplicated(worms2$Vegetation), ]
   Field.Name Area Slope Vegetation Soil.pH  Damp Worm.density
9 The.Orchard  1.9 0Orchard 5.7 FALSE9
16   Water.Meadow  3.9 0 Meadow 4.9  TRUE8
11Garden.Wood  2.910  Scrub 5.2 FALSE8
10  Rookery.Slope  1.5 4  Grassland 5.0  TRUE7
2  Silwood.Bottom  5.1 2 Arable 5.2 FALSE7
 >

Here's a one-liner involving 'with' and 'subset':
 > subset(worms[rev(order(worms$Worm.density)), ], !duplicated(Vegetation))
   Field.Name Area Slope Vegetation Soil.pH  Damp Worm.density
9 The.Orchard  1.9 0Orchard 5.7 FALSE9
16   Water.Meadow  3.9 0 Meadow 4.9  TRUE8
11Garden.Wood  2.910  Scrub 5.2 FALSE8
10  Rookery.Slope  1.5 4  Grassland 5.0  TRUE    7
2  Silwood.Bottom  5.1 2 Arable 5.2 FALSE7
 >

-- Tony Plate

[EMAIL PROTECTED] wrote:
> I'm not sure if this is a bug, or if I'm doing something wrong.
> =20
> =46rom the worms dataframe, which is at in a file called worms.txt at
> =20
> http://www.imperial.ac.uk/bio/research/crawley/therbook
> <http://www.imperial.ac.uk/bio/research/mjcraw/therbook/index.htm>=20
>
> =20
> the idea is to extract a subset of the rows, sorted in declining order
> of worm density, with only the maximum worm density from each vegetation
> type:
> =20
>
> worms<-read.table("c:\\temp\\worms.txt",header=3DT)
> attach(worms)
> names(worms)
>
> [1] "Field.Name"   "Area" "Slope""Vegetation"
> "Soil.pH"=20=20=20=20=20
> [6] "Damp" "Worm.density"
>
> =20
> Usinng "not duplicated" I get two rows for Meadow and none for Scrub
> =20
> worms[rev(order(Worm.density)),] [!duplicated(Vegetation),]
>
>Field.Name Area Slope Vegetation Soil.pH  Damp Worm.density
> 9 The.Orchard  1.9 0Orchard 5.7 FALSE9
> 16   Water.Meadow  3.9 0 Meadow 4.9  TRUE8
> 10  Rookery.Slope  1.5 4  Grassland 5.0  TRUE7
> 2  Silwood.Bottom  5.1 2 Arable 5.2 FALSE7
> 4 Rush.Meadow  2.4 5 Meadow 4.9  TRUE5
>
> and here is the correct set of rows, but in the wrong order, using
> unique
> =20
> worms[rev(order(Worm.density)),] [unique(Vegetation),]
>
>Field.Name Area Slope Vegetation Soil.pH  Damp Worm.density
> 16   Water.Meadow  3.9 0 Meadow 4.9  TRUE8
> 9 The.Orchard  1.9 0Orchard 5.7 FALSE9
> 11Garden.Wood  2.910  Scrub 5.2 FALSE8
> 2  Silwood.Bottom  5.1 2 Arable 5.2 FALSE7
> 10  Rookery.Slope  1.5 4  Grassland 5.0  TRUE7
>
> =20
> Best wishes,
> =20
> Mick
> =20
> Prof  M.J. Crawley  FRS
> =20
> Imperial College London
> Silwood Park
> Ascot
> Berks
> SL5 7PY
> UK
> =20
> Phone (0) 207 5942 216
> Fax (0) 207 5942 339
> =20
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Friday question: negative zero

[Tony Plate]

One place where I've been caught by -ve zeros is with unit tests.  If 
identical(-0, 0) returns FALSE, and the object storage doesn't preserve 
-ve zeros, that can lead to test failures that are tricky to debug.

However, it doesn't look like that is too much a problem in the current 
incarnation of R, at least running under Linux:

* identical(-0, 0) returns TRUE
* save/load preserves -ve zero
* however dump() does NOT preserve -ve zero

The fact that identical(-0,0) is TRUE means that we have the situation 
where it is possible that identical(x, y) != identical(f(x), f(y)).  I 
don't know if this is a real problem anywhere.

 > x <- 0
 > y <- -0
 > 1/x
[1] Inf
 > 1/y
[1] -Inf
 > identical(x, y)
[1] TRUE
 > ### there exists f,x,y such that identical(x, y) != identical(f(x), f(y))
 > identical(1/x, 1/y)
[1] FALSE
 > ### save/load preserves -ve zero
 > save("y", file="y.rda")
 > remove("y")
 > load("y.rda")
 > 1/y
[1] -Inf
 > identical(x, y)
[1] TRUE
 > ### dump does not preserve -ve zero
 > dump("y", file="y.R")
 > remove("y")
 > source("y.R")
 > y
[1] 0
 > 1/y
[1] Inf
 > version
   _
platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  2
minor      5.1
year   2007
month  06
day27
svn rev42083
language   R
version.string R version 2.5.1 (2007-06-27)
 >

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] append/concatenate an element to a list in C-language

[Tony Plate]

This sounds like it could be dangerous, but if you're sure it's 
necessary and you know what you are doing, you could investigate whether 
the "pairlist" internal structure might enable you to do this (AFAIK, a 
"pairlist" is a traditional linked-list data structure).  In general, 
pairlists seem to be used very little, and I've never seen their use 
encouraged, so I would be very cautious.  You can read more about 
"pairlists" under ?pairlist, in the R-internals manual, and in the 
source starting at src/include/Rinternals.h (look for "LISTSXP").

-- Tony Plate

Robert Castelo wrote:
> dear people,
>
> i need to code a function in C working in R and receives two R SEXP
> objects as parameters, where one is a list and another is a vector of
> integers:
>
> void f(SEXP list, SEXP vector) {
>
>   ...
>
>   return list;
> }
>
>
> and it should return the given list with the integer vector concatenated
> at the end (as the last element of the list). the list can be really big
> so i would not like to create a new list from scratch and copy all the
> elements, including the additional one. i'm also interested in knowing
> how should i properly handle protections of the SEXP objects when doing
> this.
>
> i've been looking at the R source code for everything that has to do
> with CAR, CDR, CONS, and even found functions with promising names like
> listAppend or GrowList but i have not been able to figure this out nor i
> haven't been able to find any reference on how to do this by googling
> all around, so any help will be very much appreciated.
>
>
> thanks a lot!!!
>
> robert.
>
> __
> 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] pairs, par

[Tony Plate]

I would look into the code for pairs().  Among other things, it sets and 
restores par(mfrow=...).  I suspect this is the relevant issue, not the 
use of pairs().  I would try to figure out what state a graphics device 
is in after resetting par("mfrow").  When I try the following (R 2.6.0 
patched, under Windows), I see a line on the plot, but not in a place 
that corresponds to the axis that were drawn by the 'plot()' command:

 > par(mfrow=c(2,2))
 > plot(1:2)
 > par(mfrow=c(1,1))
 > lines(1:2,1:2)
 >

(and if you want to be able to set up a new coordinate system on the 
plotting device to draw on top of the plot left by pairs(), look at 
par("new") & something like plot(0:1, type='n', axes=F, xlab=""))

hope this helps,

Tony Plate

Oliver Soong wrote:
> Hi,
>
> I posted over at R-help, and didn't get a response, but perhaps that
> was the wrong forum for this question.  I'm having some confusion over
> the coordinate system after using pairs.  I'm not interested in the
> content of the actual pairs plot, although the number of pairs seems
> to matter a bit.  I'm purely interested in knowing where subsequent
> points will be plotted on the device.  However, after using pairs, the
> par information (omd, fig, plt, and usr) don't reflect what points
> does.  For example:
>
> pairs(iris[1:5])
> par(xpd = NA)
> points(0 - 0.01 * 1:100, 0 - 0.01 * 1:100)
> points(0 - 0.01 * 1:100, 1 + 0.01 * 1:100)
> points(1 + 0.01 * 1:100, 0 - 0.01 * 1:100)
> points(1 + 0.01 * 1:100, 1 + 0.01 * 1:100)
> par(c("omd", "fig", "plt", "usr"))
>
> The resulting plot shows that the corners of the are approximately
> 0.05 user coordinate units from the boundaries of the plot region.
> According to par, though, there is a margin around the plotting region
> that is clearly not symmetric and does not correspond to around 0.05
> units.
>
> If we use pairs(iris[1:2]) and repeat the rest, the corners are now
> 0.02 user coordinate units.  par provides the same information as
> before.
>
> So:
> 1. How do I figure out where coordinates I give to points will display
> on the figure?
> 2. More generally (for my own understanding), why does the par
> information not do what I expect?  Do I have some fundamental
> misunderstanding of the arrangement of plotting, figure, display, and
> margin regions within the device?  Is there a bug in pairs and/or par?
>
> I'm using R 2.5.1, and this behavior occurs on a fresh R console.
>
> Thanks!
>
> Oliver
>
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] sd(NA)

[Tony Plate]

I also prefer the old behavior.  The old behavior of sd (return NA 
rather than stop with an error) is nicer when one is working with any 
kind of resampling technique.  If there are some NA's in the data, then 
one can happily "debug" with a small or medium number of samples, and 
only when running a full resample will one get a sample containing all 
NA's, which triggers the error and aborts the whole computation (and of 
course the times this caused the loss of several hours of computation by 
happening close to the end are most easily remembered.)

In R-devel (2.7.0), the following behavior occurs with various 
summary/statistics functions when given a vector of all NA (& na.rm=T):

sd, var: stop with error
mean, mad, median, IQR, quantile, fivenum: return NA
min, max, range: warn & return NA

Is the "stop with error" behavior really that useful with sd() & var() 
that these functions should differ in their behavior from mean(), mad(), 
etc?

Personally, I'd find it most convenient if all these functions just 
returned NA values (without warning) when unable to compute a value.

-- Tony Plate

[resent because http://www.orbitrbl.com/ is blocking emails from one of 
my ISPs]

Patrick Burns wrote:
> I like the 2.6.x behaviour better.  Consider:
>
> x <- array(1:30), c(10,3))
> x[,1] <- NA
> x[-1,2] <- NA
> x[1,3] <- NA
>
> sd(x, na.rm=TRUE)
>
> # 2.7.0
> Error in var(x, na.rm = na.rm) : no complete element pairs
>
> # 2.6.x
> [1]   NA   NA 2.738613
>
> The reason to put 'na.rm=TRUE' into the call is to avoid
> getting an error due to missing values. (And, yes, in finance
> it is entirely possible to have a matrix with all NAs in a
> column.)
>
> I think the way out is to allow there to be a conceptual
> difference between computing a value with no data, and
> computing a value on all NAs after removing NAs.  The
> first is clearly impossible.  The second has some actual
> value, but we don't have enough information to have an
> estimate of the value.
>
> Patrick Burns
> [EMAIL PROTECTED]
> +44 (0)20 8525 0696
> http://www.burns-stat.com
> (home of S Poetry and "A Guide for the Unwilling S User")
>
> Prof Brian Ripley wrote:
>
>   
>> On Sun, 2 Dec 2007, Wolfgang Huber wrote:
>>
>>  
>>
>> 
>>> Dear Prof. Ripley
>>>
>>> I noted a change in the behaviour of "cov", which is very reasonable:
>>>
>>> ## R version 2.7.0 Under development (unstable) (2007-11-30 r43565)
>>>
>>>
>>>   
>>>> cov(as.numeric(NA), as.numeric(NA), use="complete.obs")
>>>>  
>>>>
>>>> 
>>> Error in cov(as.numeric(NA), as.numeric(NA), use = "complete.obs") :
>>>  no complete element pairs
>>>
>>> whereas earlier behavior was, for example:
>>> ## R version 2.6.0 Patched (2007-10-23 r43258)
>>>
>>>
>>>   
>>>> cov(as.numeric(NA), as.numeric(NA), use="complete.obs")
>>>>  
>>>>
>>>> 
>>> [1] NA
>>>
>>>
>>> I wanted to ask whether the effect this has on "sd" is desired:
>>>
>>> ## R version 2.7.0 Under development (unstable) (2007-11-30 r43565)
>>>
>>>
>>>   
>>>> sd(NA, na.rm=TRUE)
>>>>  
>>>>
>>>> 
>>> Error in var(x, na.rm = na.rm) : no complete element pairs
>>>
>>> ## R version 2.6.0 Patched (2007-10-23 r43258)
>>>
>>>
>>>   
>>>> sd(NA, na.rm=TRUE)
>>>>  
>>>>
>>>> 
>>> [1] NA
>>>
>>>
>>>   
>> That is a bug fix: see the NEWS entry.  The previous behaviour of
>>
>>  
>>
>> 
>>> sd(numeric(0))
>>>
>>>
>>>   
>> Error in var(x, na.rm = na.rm) : 'x' is empty
>>  
>>
>> 
>>> sd(NA_real_, na.rm=TRUE)
>>>
>>>
>>>   
>> [1] NA
>>
>> was not as documented:
>>
>>  This function computes the standard deviation of the values in
>>  'x'. If 'na.rm' is 'TRUE' then missing values are removed before
>>  computation proceeds.
>>
>> so somehow an empty vector had a sd() if computed one way, and not if 
>> computed another.
>>
>>  
>>
>> 
>
> __
> 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] Interactiveness

[Tony Plate]

Bjarni Juliusson wrote:
> Prof Brian Ripley wrote:
>   
>> On Tue, 11 Dec 2007, Bjarni Juliusson wrote:
>> 
>>> I'm developing R integration for a project called Bioclipse at Uppsala
>>> University. The current implementation works by simply forking an R and
>>> sending it text (with some substitutions on it) down a pipe, getting the
>>> printed output back up another pipe. This of course works fine, except
>>> it runs into one problem: R finds a pipe on its stdin and decides to be
>>> "non-interactive", which means that as soon as the user makes a typo and
>>> causes an error, R exits.
>>>   
>> Actually, not so.  The default error handler for non-interactive use is 
>> to do that, but you can change it.
>> 
>
> Could you perhaps just point me in the right direction here? I really 
> have no idea how to do this.
>   
Specify a non-NULL error handler by doing something like this:
 > options(error=dump.frames)
See ?options (look for "error") and ?stop for more details.

-- Tony Plate

> Also, what exactly does non-interactive mode imply, besides this default 
> error handling behaviour?
>
>   
>>> I checked the source, and it's a couple of isatty()'s in the two files
>>> named system.c that are doing it. They are of course intended to be a
>>> feature, but in this case it causes us trouble. Would it be possible to
>>> get a command line switch to control this behaviour? I'm not sure pseudo
>>> terminals can be used portably, or can they?
>>>   
>> They can, and are e.g. by ESS (except on Windows, where there is already 
>> a switch).  I think you need to look a bit more carefully at what other 
>> projects do.
>> 
>
> It needs to be portable to Windows. I'll look into this possibility next.
>
> Didn't mean to ask before I had done my homework. Thanks for your help!
>
>
> Bjarni
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Wrong length of POSIXt vectors (PR#10507)

[Tony Plate]

Duncan Murdoch wrote:
> On 12/11/2007 6:20 AM, [EMAIL PROTECTED] wrote:
>> Full_Name: Petr Simecek
>> Version: 2.5.1, 2.6.1
>> OS: Windows XP
>> Submission from: (NULL) (195.113.231.2)
>>
>>
>> Several times I have experienced that a length of a POSIXt vector has not 
>> been
>> computed right.
>>
>> Example:
>>
>> tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
>> ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
>> ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 
>> 12L), mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 
>> 13L), mon = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L, 
>> 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday = c(1L, 
>> 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 163L, 
>> 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L, 
>> 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", 
>> "min", "hour", "mday", "mon", "year", "wday", "yday", "isdst"
>> ), class = c("POSIXt", "POSIXlt"))
>>
>> print(tv)
>> # print 11 time points (right)
>>
>> length(tv)
>> # returns 9 (wrong)
> 
> tv is a list of length 9.  The answer is right, your expectation is wrong.
>> I have tried that on several computers with/without switching to English
>> locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a help pages 
>> but I
>> cannot imagine how that could be OK.
> 
> See this in ?POSIXt:
> 
> Class '"POSIXlt"' is a named list of vectors...
> 
> You could define your own length measurement as
> 
> length.POSIXlt <- function(x) length(x$sec)
> 
> and you'll get the answer you expect, but be aware that length.XXX 
> methods are quite rare, and you may surprise some of your users.
> 

On the other hand, isn't the fact that length() currently always returns 9 
for POSIXlt objects likely to be a surprise to many users of POSIXlt?

The back of "The New S Language" says "Easy-to-use facilities allow you to 
organize, store and retrieve all sorts of data. ... S functions and data 
organization make applications easy to write."

Now, POSIXlt has methods for c() and vector subsetting "[" (and many other 
vector-manipulation methods - see methods(class="POSIXlt")).  Hence, from 
the point of view of intending to supply "easy-to-use facilities ... [for] 
all sorts of data", isn't it a little incongruous that length() is not also 
provided -- as 3 functions (any others?) comprise a core set of 
vector-manipulation functions?

Would it make sense to have an informal prescription (e.g., in R-exts) that 
a class that implements a vector-like object and provides at least of one 
of functions 'c', '[' and 'length' should provide all three?  It would also 
be easy to describe a test-suite that should be included in the 'test' 
directory of a package implementing such a class, that had some tests of 
the basic vector-manipulation functionality, such as:

 > # at this point, x0, x1, x3, & x10 should exist, as vectors of the
 > # class being tested, of length 0, 1, 3, and 10, and they should
 > # contain no duplicate elements
 > length(x0)
[1] 1
 > length(c(x0, x1))
[1] 2
 > length(c(x1,x10))
[1] 11
 > all(x3 == x3[seq(len=length(x3))])
[1] TRUE
 > all(x3 == c(x3[1], x3[2], x3[3]))
[1] TRUE
 > length(c(x3[2], x10[5:7]))
[1] 4
 >

It would also be possible to describe a larger set of vector manipulation 
functions that should be implemented together, including e.g., 'rep', 
'unique', 'duplicated', '==', 'sort', '[<-', 'is.na', head, tail ... (many 
of which are provided for POSIXlt).

Or is there some good reason that length() cannot be provided (while 'c' 
and '[' can) for some vector-like classes such as "POSIXlt"?

-- Tony Plate

> 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] Rapid Random Access

[Tony Plate]

Barry Rowlingson wrote:
>   I have some code that can potentially produce a huge number of 
> large-ish R data frames, each of a different number of rows. All the 
> data frames together will be way too big to keep in R's memory, but 
> we'll assume a single one is manageable. It's just when there's a 
> million of them that the machine might start to burn up.
>   
This is exactly the type of situation that the trackObjs package is 
designed for.  It will automatically (and invisibly) store each object 
in its own .RData file so that objects can be accessed as ordinary R 
objects, but are not kept in memory (actually, there are options to 
control whether or not objects are cached in memory). It also caches 
some characteristics of objects so that a brief summary of objects can 
be provided without having to read each object.  The g.data package and 
the filehash package also do similar things wrt to providing automatic 
access to objects in .RData files (and were part of the inspiration for 
the trackObjs package.)

-- Tony Plate
>   However I might, for example, want to compute some averages over the 
> elements in the data frames. Or I might want to sample ten of them at 
> random and do some plots. What I need is rapid random access to data 
> stored in external files.
>
>   Here's some ideas I've had:
>
>   * Store all the data in an HDF-5 file - problem here is that the 
> current HDF package for R reads the whole file in at once.
>
>   * Store the data in some other custom binary format with an index for 
> rapid access to the N-th elements. Problems: feels like reinventing HDF, 
> cross-platform issues, etc.
>
>   * Store the data in a number of .RData files in a directory. Hence to 
> get the N-th element just attach(paste("foo/A-",n,'.RData')) give or 
> take a parameter or two.
>
>   * Use a database. Seems a bit heavyweight, but maybe using RSQLite 
> could work in order to keep it local.
>
>   What I'm currently doing is keeping it OO enough that I can in theory 
> implement all of the above. At the moment I have an implementation that 
> does keep them all in R's memory as a list of data frames, which is fine 
> for small test cases but things are going to get big shortly. Any other 
> ideas or hints are welcome.
>
> thanks
>
> Barry
>
> __
> 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] Wrong length of POSIXt vectors (PR#10507)

[Tony Plate]

Duncan Murdoch wrote:
> On 12/13/2007 1:59 PM, Tony Plate wrote:
>> Duncan Murdoch wrote:
>>> On 12/11/2007 6:20 AM, [EMAIL PROTECTED] wrote:
>>>> Full_Name: Petr Simecek
>>>> Version: 2.5.1, 2.6.1
>>>> OS: Windows XP
>>>> Submission from: (NULL) (195.113.231.2)
>>>>
>>>>
>>>> Several times I have experienced that a length of a POSIXt vector 
>>>> has not been
>>>> computed right.
>>>>
>>>> Example:
>>>>
>>>> tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
>>>> ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
>>>> ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 12L), 
>>>> mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 13L), mon 
>>>> = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L, 
>>>> 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday = 
>>>> c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 163L, 
>>>> 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L, 
>>>> 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", "min", 
>>>> "hour", "mday", "mon", "year", "wday", "yday", "isdst"
>>>> ), class = c("POSIXt", "POSIXlt"))
>>>>
>>>> print(tv)
>>>> # print 11 time points (right)
>>>>
>>>> length(tv)
>>>> # returns 9 (wrong)
>>>
>>> tv is a list of length 9.  The answer is right, your expectation is 
>>> wrong.
>>>> I have tried that on several computers with/without switching to 
>>>> English
>>>> locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a 
>>>> help pages but I
>>>> cannot imagine how that could be OK.
>>>
>>> See this in ?POSIXt:
>>>
>>> Class '"POSIXlt"' is a named list of vectors...
>>>
>>> You could define your own length measurement as
>>>
>>> length.POSIXlt <- function(x) length(x$sec)
>>>
>>> and you'll get the answer you expect, but be aware that length.XXX 
>>> methods are quite rare, and you may surprise some of your users.
>>>
>>
>> On the other hand, isn't the fact that length() currently always 
>> returns 9 for POSIXlt objects likely to be a surprise to many users 
>> of POSIXlt?
>>
>> The back of "The New S Language" says "Easy-to-use facilities allow 
>> you to organize, store and retrieve all sorts of data. ... S 
>> functions and data organization make applications easy to write."
>>
>> Now, POSIXlt has methods for c() and vector subsetting "[" (and many 
>> other vector-manipulation methods - see methods(class="POSIXlt")).  
>> Hence, from the point of view of intending to supply "easy-to-use 
>> facilities ... [for] all sorts of data", isn't it a little 
>> incongruous that length() is not also provided -- as 3 functions (any 
>> others?) comprise a core set of vector-manipulation functions?
>>
>> Would it make sense to have an informal prescription (e.g., in 
>> R-exts) that a class that implements a vector-like object and 
>> provides at least of one of functions 'c', '[' and 'length' should 
>> provide all three?  It would also be easy to describe a test-suite 
>> that should be included in the 'test' directory of a package 
>> implementing such a class, that had some tests of the basic 
>> vector-manipulation functionality, such as:
>>
>>  > # at this point, x0, x1, x3, & x10 should exist, as vectors of the
>>  > # class being tested, of length 0, 1, 3, and 10, and they should
>>  > # contain no duplicate elements
>>  > length(x0)
>> [1] 1
>>  > length(c(x0, x1))
>> [1] 2
>>  > length(c(x1,x10))
>> [1] 11
>>  > all(x3 == x3[seq(len=length(x3))])
>> [1] TRUE
>>  > all(x3 == c(x3[1], x3[2], x3[3]))
>> [1] TRUE
>>  > length(c(x3[2], x10[5:7]))
>> [1] 4
>>  >
>>
>> It would also be possible to describe a larger set of vector 
>> manipulation functions that should be implemented together, including 
>> e.g., 'rep', 'unique', 'duplicated', '==', 'sort', '[<-', 'is.na', 
>> 

[Rd] guidelines for consistency of vector functions

[Tony Plate]

Moving on from the discussion of the fact that length(x)==9 for any 
POSIXlt object x (which seems diabolically confusing, given that 'c' and 
'[' are defined for POSIXlt and have the vector-like behavior one would 
expect), what about having some guidelines for coding and documentation 
of vector-like classes?


(1) a vector-like class should implement functions in groups:
   level 1: 'c', '[', 'length'
   level 2: 'x[i] <- value', 'rep', 'unique', 'duplicated'
   level 3: 'head', 'tail', 'sort'
   NA group: 'is.na' 'x[i] <- NA' 'is.na(x) <- TRUE'
   character coercion: 'as.character', 'as..character'
   names group: 'names()' 'names()<-'

[should '==', 'all.equal' be included anywhere]

If any member of a group is implemented, then it is considered good 
style to implement the others.


(2) conformance or deviation from this guideline should be documented on 
the help page for the class.


These could go in a section of R-ext, and a function that automatically 
checks conformance could also be supplied as part of R.  A rough version 
of such a function is attached.


This would have the following benefits:

(1) developers would have guidelines and tools to help them write 
classes that behave in a way that users expect


(2) users would know better what to expect, both in general, and in 
specific cases where developers followed the documentation guidelines.


(3) observance of the guidelines would be an indicator of software 
quality (no evidence of any attention to the guidelines would be a sign 
that the code was more of an experiment than a piece of software that 
was carefully engineered for widespread use.)


All of the above is a rough draft that could be discussed further (e.g., 
should '[.<-' go in level 1 or level 2?) if there was any interest in 
pursuing this suggestion.


Comments?

-- Tony Plate

PS:

Here's a few examples of running an automatic vector-functionality 
tester on some vector-like classes in R ("basic"="level 1", 
"extra"="level 2", and "bonus"="level 3" functions) (this might be hard 
to read if line wrapping happens -- I've attached text files):


> source("testVectorFunctionality.R")
> library(chron)
> if (exists("length.POSIXlt")) remove(list="length.POSIXlt")
>
> ### 'character' passes the functionality tests
> res <- testVectorFunctionality(CLASS="character", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'numeric' passes the functionality tests
> res <- testVectorFunctionality(CLASS="numeric", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'integer' passes the functionality tests
> res <- testVectorFunctionality(CLASS="integer", verbose=FALSE)
Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### 'Date' passes the functionality tests
> res <- testVectorFunctionality(from.numeric=function(i) 
as.Date("2001/01/01") + i, verbose=FALSE)

Passed all 17 basic tests, 17 extra tests, and 5 bonus tests
>
> ### chron 'times' passes the basic, but not the extra functionality tests
> res <- testVectorFunctionality(from.numeric=function(i) 
chron(times=i), verbose=FALSE)

Failed 0 of 17 basic tests, 12 of 17 extra tests, and 0 of 0 bonus tests
> res <- testVectorFunctionality(from.numeric=function(i) 
chron(times=i), verbose=TRUE)

Testing basic vector functionality for class 'times'
Testing extra vector functionality for class 'times'
  Failed consistency check: unique(xa) == xa
  Failed consistency check: unique(xb) == xb
  Failed consistency check: unique(x0) == x0
  Failed consistency check: unique(x1) == x1
  Failed consistency check: unique(xA) == xA[!duplicated(xA)]
  Failed consistency check: rep(x1, 3) == c(x1, x1, x1)
  Failed consistency check: rep(xa, 3) == c(xa, xa, xa)
  Failed consistency check: rep(xb, 2) == c(xb, xb)
  Failed consistency check: rep(x1, 0) == x1[0]
  Failed consistency check: rep(xa, each = 3) == xa[rep(seq(len = 
xa.len), each = 3)]
  Failed consistency check: rep(xb, each = 2) == xb[rep(seq(len = 
xb.len), each = 2)]
  Failed consistency check: rep(xa, length.out = xa.len + 1) == c(xa, 
xa[1])

In 17 basic consistency tests on 'times', had the following outcomes: ok:17
  'ok' tests (17) involved: '[':4, c:9, length:9
In 17 extra consistency tests on 'times', had the following outcomes: 
failure:12, ok:5

  'failure' tests (12) involved: duplicated:1, rep:7, unique:5
  'ok' tests (5) invo

Re: [Rd] Wrong length of POSIXt vectors (PR#10507)

[Tony Plate]

Duncan Murdoch wrote:
> On 15/12/2007 5:17 PM, Martin Maechler wrote:
>>>>>>> "TP" == Tony Plate <[EMAIL PROTECTED]>
>>>>>>> on Fri, 14 Dec 2007 13:58:30 -0700 writes:
>>     TP> Duncan Murdoch wrote:
>> >> On 12/13/2007 1:59 PM, Tony Plate wrote:
>> >>> Duncan Murdoch wrote:
>> >>>> On 12/11/2007 6:20 AM, [EMAIL PROTECTED] wrote:
>> >>>>> Full_Name: Petr Simecek
>> >>>>> Version: 2.5.1, 2.6.1
>> >>>>> OS: Windows XP
>> >>>>> Submission from: (NULL) (195.113.231.2)
>> >>>>> 
>> >>>>> 
>> >>>>> Several times I have experienced that a length of a POSIXt vector 
>> >>>>> has not been
>> >>>>> computed right.
>> >>>>> 
>> >>>>> Example:
>> >>>>> 
>> >>>>> tv<-structure(list(sec = c(50, 0, 55, 12, 2, 0, 37, NA, 17, 3, 31
>> >>>>> ), min = c(1L, 10L, 11L, 15L, 16L, 18L, 18L, NA, 20L, 22L, 22L
>> >>>>> ), hour = c(12L, 12L, 12L, 12L, 12L, 12L, 12L, NA, 12L, 12L, 12L), 
>> >>>>> mday = c(13L, 13L, 13L, 13L, 13L, 13L, 13L, NA, 13L, 13L, 13L), 
>> mon 
>> >>>>> = c(5L, 5L, 5L, 5L, 5L, 5L, 5L, NA, 5L, 5L, 5L), year = c(105L, 
>> >>>>> 105L, 105L, 105L, 105L, 105L, 105L, NA, 105L, 105L, 105L), wday = 
>> >>>>> c(1L, 1L, 1L, 1L, 1L, 1L, 1L, NA, 1L, 1L, 1L), yday = c(163L, 
>> 163L, 
>> >>>>> 163L, 163L, 163L, 163L, 163L, NA, 163L, 163L, 163L), isdst = c(1L, 
>> >>>>> 1L, 1L, 1L, 1L, 1L, 1L, -1L, 1L, 1L, 1L)), .Names = c("sec", 
>> "min", 
>> >>>>> "hour", "mday", "mon", "year", "wday", "yday", "isdst"
>> >>>>> ), class = c("POSIXt", "POSIXlt"))
>> >>>>> 
>> >>>>> print(tv)
>> >>>>> # print 11 time points (right)
>> >>>>> 
>> >>>>> length(tv)
>> >>>>> # returns 9 (wrong)
>> >>>> 
>> >>>> tv is a list of length 9.  The answer is right, your expectation is 
>> >>>> wrong.
>> >>>>> I have tried that on several computers with/without switching to 
>> >>>>> English
>> >>>>> locales, i.e. Sys.setlocale("LC_TIME", "en"). I have searched a 
>> >>>>> help pages but I
>> >>>>> cannot imagine how that could be OK.
>> >>>> 
>> >>>> See this in ?POSIXt:
>> >>>> 
>> >>>> Class '"POSIXlt"' is a named list of vectors...
>> >>>> 
>> >>>> You could define your own length measurement as
>> >>>> 
>> >>>> length.POSIXlt <- function(x) length(x$sec)
>> >>>> 
>> >>>> and you'll get the answer you expect, but be aware that length.XXX 
>> >>>> methods are quite rare, and you may surprise some of your users.
>> >>>> 
>> >>> 
>> >>> On the other hand, isn't the fact that length() currently always 
>> >>> returns 9 for POSIXlt objects likely to be a surprise to many users 
>> >>> of POSIXlt?
>> >>> 
>> >>> The back of "The New S Language" says "Easy-to-use facilities allow 
>> >>> you to organize, store and retrieve all sorts of data. ... S 
>> >>> functions and data organization make applications easy to write."
>> >>> 
>> >>> Now, POSIXlt has methods for c() and vector subsetting "[" (and many 
>> >>> other vector-manipulation methods - see methods(class="POSIXlt")).  
>> >>> Hence, from the point of view of intending to supply "easy-to-use 
>> >>> facilities ... [for] all sorts of data", isn't it a little 
>> >>> incongruous that length() is not also provided -- as 3 functions 
>> (any 
>> >>> others?) comprise a core set of vector-mani

Re: [Rd] Wrong length of POSIXt vectors (PR#10507)

[Tony Plate]

Jeffrey J. Hallman wrote:
> Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
>   
>> One reason I don't want to work on this is because the appropriate 
>> action depends on what "length(x)" is intended to mean.  Currently for 
>> POSIXlt objects, it gives the physical length of the underlying basic 
>> type (the list).  This is the same behaviour as we have for matrices, 
>> data frames and every other object without a specific length method, so 
>> it's not outrageous.
>>
>> The proposed change is to have it return the logical length of the 
>> object, which also seems quite reasonable.  I don't think matrices and 
>> data frames have a "logical length", so there would be no contradiction 
>> in those examples.  The thing that worries me is that there are probably 
>> objects in packages where both logical length and physical length make 
>> sense but are different.  I don't have any expectation that length(x) on 
>> those currently is consistent in which type of value it returns.
>>
>> If we were to decide that "length(x)" *always* meant logical length, 
>> then we would have a problem:  matrices and data frames don't have a 
>> logical length, so we shouldn't be getting an answer there.  Changing 
>> length(x) for those is not acceptable.
>>
>> On the other hand, if we decide that "length(x)" *always* means physical 
>> length, we don't need to do anything to the POSIXlt or matrices or data 
>> frames, but there may well be other kinds of objects out there that 
>> violate this rule.
>>
>> We could leave the meaning of length(x) ambiguous.  If you want to know 
>> what it does for a POSIXlt object, you need to read the documentation or 
>> look at the source code.  As a policy, this isn't particularly 
>> appealing, but I could probably live with it if someone else did the 
>> research and showed that current usage is ambiguous.
>> 
>
> Physical length and logical length are, as you say, two different things.  So
> why not two functions?  Keep length() for physical length, as it is now, and
> maybe Length() for logical length.  The latter could be defined as
>
> Length <- function(x, ...) UseMethod("Length")
>
> Length.default <- function(x, ...) length(x)
>
> and then add methods for classes that want something else.
>   
A very reasonable suggestion, but I'd also put this in the "next time we 
design a language" category.

The current system in R seems workable to me, if one knows that 
vector-like classes that have a S3 list-based implementation need to 
have methods defined for 'c', 'length', '[', etc, and that if these 
methods aren't defined, then you'll be operating on the underlying list 
structure.  Where these methods are defined, one can get at the 
underlying structure by unclassing first, and that's OK.  However, 
classes that have some of these methods defined but not others seem to 
me to be needlessly confusing -- it's not like there any great benefit 
that length() always returns the length of the underlying list for 
POSIXlt -- if there was a length() method one could get at the 
underlying length using length(unclass(x)).  It just seems like a design 
oversight that makes using such classes unnecessarily difficult and 
error-prone.

Hence my proposal (in a new thread) for coding & documentation 
guidelines that would that would:
(1) suggest consistency is a good thing
(2) suggent compliance or deviation should be documented
(3) define what consistency was (and here it's not so important to get 
absolutely the right set of consistency definitions as it is to get a 
reasonable set that people agree on.)

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] as.Date.numeric origin default

[Tony Plate]

Seems like it makes sense to have a default origin of 1970-01-01 for 
as.Date.numeric().  Are there any strong arguments for requiring users 
to specify the origin for every invocation of as.Date.numeric()?

The code could be:

as.Date.numeric <- function(x, origin="1970-01-01", ...)
{
if ((missing(origin) && nargs()==1)
|| (is.character(origin) && origin=="1970-01-01" && nargs()==2))
return(structure(as.integer(x), class="Date"))
as.Date(origin, ...) + as.integer(x)
}

I guess the use of as.integer(x) is debatable, but using it seems 
consistent with the "Details" section of ?Date.

-- Tony Plate

Jeff Ryan wrote:
> R-devel,
>
> I would like to second Gabor Grothendieck's request from September (
> http://www.nabble.com/as.Date.numeric-to12962733.html#a12962733 )
> on adding a default value (1970-01-01) to the origin argument of
> as.Date.numeric.
>
> I realize there is good reason to allow for origin to be specified,
> but I don't see why it must be up to the user at each and every
> invocation if most (if not all) users will simply be using 1970-01-01.
>
> My first contact was building quantmod for CRAN - many more hidden
> errors occur as I test  on R-devel.  It just seems to me to be an easy
> compromise to what will undoubtedly cost many hours of debugging
> across all packages/users.
>
> Thank you for your consideration,
> Jeff Ryan
>
> __
> 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] is(x, "parent") returns FALSE when class(x) is c("child", "parent") (PR#10549)

[Tony Plate]

[EMAIL PROTECTED] wrote:
>>>>>> "TimH" == timh  <[EMAIL PROTECTED]>
>>>>>> on Sat,  5 Jan 2008 02:05:08 +0100 (CET) writes:
>>>>>> 
>
> TimH> is() does not catch parent S3 classes:
>
> >> library(splines)
> >> temp <- bs(1:99, df=5)
> >> class(temp)
> TimH> [1] "bs""basis"
> >> is(temp, "basis")
> TimH> [1] FALSE
>
> TimH> In contrast, is() does catch parent S4 classes:
> >> library(copula)
> >> norm.cop <- ellipCopula("normal", param = c(0.5, 0.6, 0.7),
> TimH> + dim = 3, dispstr = "un")
> >> is(norm.cop, "copula")
> TimH> [1] TRUE
> >> class(norm.cop)
> TimH> [1] "normalCopula"
>
> Yes, that's all correct, but where's the bug?
>
> S3 has *NO* class definitions, so how can there be class
> inheritance?
>   
These types of statements make me really confused (and I suspect far 
more than necessary).  Isn't 'inherits()' an S3 function?  (at least 
it's not in package "methods", and it works with S3 classes, while 'is' 
is in the "methods" package).

The inherits documentation says:
Details:

 Many R objects have a 'class' attribute, a character vector giving
 the names of the classes from which the object _inherits_. If the
 object does not have a class attribute, it has an implicit class,
 '"matrix"', '"array"' or the result of 'mode(x)' (except that
 integer vectors have implicit class '"integer"').  (Functions
 'oldClass' and 'oldClass<-' get and set the attribute, which can
 also be done directly.)

But if S3 has no class definitions, and that fact precludes class 
inheritance, how come the inherits() functions exists and works with S3 
"classes" and inherits() documentation talks about classes and inheritance?

And it looks like 'inherits()' does what (I think) Tim Hesterberg is 
looking for:

 > x <- structure(1, class=c("a", "ab", "abc"))
 > is(x, "a")
[1] TRUE
 > is(x, "ab")
[1] FALSE
 > inherits(x, "a")
[1] TRUE
 > inherits(x, "ab")
[1] TRUE
 >


> There's many reasons to go from S3 to S4, and the lack of class
> definitions in S3 is an important one...
>
> Now, still being curious:  Are you implicitly saying that in S-plus,
> is() behaves differently, namely 
> ``as if S3 classes would exist?'' (:-)
>   
Is S-PLUS 7.0, I see the following behavior:

 > x <- structure(1, class=c("a", "ab"))
Warning in checkOldClass(c("a", "ab")): No formal definition of 
old-style inheritance; consider setOldClass(c("a",
 "ab"))
 > inherits(x, "a")
[1] T
 > inherits(x, "ab")
[1] T
 > is(x, "a")
[1] T
 > is(x, "ab")
[1] T
 >

Which would make it appear that in S-PLUS, for objects with S3 classes 
the function "is" uses the definition of the concept "inherits" that 
appears in the R documentation for the function "inherits" :-)  (But, 
apparently, S3 classes don't exist, so does that make R an imaginary 
language except when one uses S4 classes? :-)

-- Tony Plate

> [Of course, I understand what you mean, and I agree that
>  normally, the S3  class attribute  c("ch", "pr") means that "ch"
>  is conceptually a child of "pr".
>  
>  However, there's at least one exception in R {which I have found a
>  bit unfortunate, but never followed up}:
>
>> class(Sys.time())
>[1] "POSIXt"  "POSIXct"
> ]
>
> Regards,
> Martin
>
> TimH> Version:
> .
> TimH> version.string = R version 2.6.1 (2007-11-26)
> .
>
> __
> 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] as.function()

[Tony Plate]

How about this as a version  that automatically constructs the argument 
list (and make into a method for as.function as appropriate)?

makefun <- function(expr)
{
f <- function() {}
body(f) <- expr
vars <- all.vars(expr)
if (length(vars)) {
args <- alist(x=)[rep(1,length(vars))]
names(args) <- vars
formals(f) <- args
}
environment(f) <- globalenv()
return(f)
}

 > makefun(expression(2*x + 3*y^2))
function (x, y)
2 * x + 3 * y^2
 > makefun(expression(2*x + 3*y^2 - z))
function (x, y, z)
2 * x + 3 * y^2 - z
 > makefun(expression(p1 + p2))
function (p1, p2)
p1 + p2
 >

-- Tony Plate



Henrique Dallazuanna wrote:
> Try this:
>
> as.function.foo <- function(obj, ...)
> {
> newobj <- function(x, ...){}
> body(newobj) <- obj
> return(newobj)
> }
>
> x <- expression(2*x + 3*x^2)
>
> foo <- as.function.foo(x)
> foo(2)
>
>
> Hope this help
>
> On 14/01/2008, Robin Hankin <[EMAIL PROTECTED]> wrote:
>   
>> Antonio
>>
>>
>> thanks for your help here, but it doesn't answer my question.
>>
>> Perhaps if I outline my motivation it would help.
>>
>>
>> I want to recreate the ability of
>> the "polynom" package to do the following:
>>
>>
>>  > library(polynom)
>>  > p <- polynomial(1:4)
>>  > p
>> 1 + 2*x + 3*x^2 + 4*x^3
>>  > MySpecialFunction <- as.function(p)
>>  > MySpecialFunction(1:10)
>>   [1]   10   49  142  313  586  985 1534 2257 3178 4321
>>  > p <- 4
>>  > MySpecialFunction(1:10)
>>   [1]   10   49  142  313  586  985 1534 2257 3178 4321
>>  >
>>
>>
>> See how the user can define object "MySpecialFunction",
>>   which outlives short-lived polynomial "p".
>>
>> Unfortunately, I don't see a way to modify as.function.polynomial()
>> to do what I want.
>>
>>
>> best wishes
>>
>>
>> rksh
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 14 Jan 2008, at 08:45, Antonio, Fabio Di Narzo wrote:
>>
>> 
>>> 2008/1/14, Robin Hankin <[EMAIL PROTECTED]>:
>>>   
>>>> Hi
>>>>
>>>> [this after some considerable thought as to R-help vs R-devel]
>>>>
>>>>
>>>>
>>>> I want to write a (S3) method for as.function();
>>>> toy example follows.
>>>>
>>>> Given a matrix "a", I need to evaluate trace(ax) as a function of
>>>> (matrix) "x".
>>>>
>>>> Here's a trace function:
>>>>
>>>> tr <-  function (a)  {
>>>> i <- seq_len(nrow(a))
>>>> return(sum(a[cbind(i, i)]))
>>>> }
>>>>
>>>>
>>>> How do I accomplish the following:
>>>>
>>>>
>>>> a <- crossprod(matrix(rnorm(12),ncol=3))
>>>> class(a) <- "foo"
>>>>
>>>> f <- as.function(a)   # need help to write as.function.foo()
>>>> x <- diag(3)
>>>>
>>>> f(x) #should give tr(ax)
>>>> 
>>> What about the following?
>>>
>>> as.function.foo <- function(a, ...)
>>>  function(x)
>>>sum(diag(a*x))
>>>
>>> However, I don't see the need for an S3 method. Why don't simply use
>>> (?):
>>> mulTraceFun <- function(a)
>>>  function(x)
>>>   sum(diag(a*x))
>>>
>>> So you also have a more meaningful name than an anonymous
>>> 'as.function'.
>>>
>>> HTH,
>>> Antonio.
>>>
>>>   
>>>> a <- 4
>>>> f(x)   # should still give tr(ax) even though "a" has been
>>>> reassigned.
>>>> 
>>> This would'nt work with my proposal, because of lexical scoping.
>>>
>>>   
>>>>
>>>>
>>>>
>>>> [my real example is very much more complicated than this but
>>>> I need this toy one too and I can't see how to modify
>>>> as.function.polynomial()
>>>> to do what I want]
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Robin Hankin
>>>> Uncertainty Analyst and Neutral Theorist,
>>>> National Oceanography Centre, Southampton
>>>> European Way, Southampton SO14 3ZH, UK
>>>>  tel  023-8059-7743
>>>>
>>>> __
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>> 
>>> --
>>> Antonio, Fabio Di Narzo
>>> Ph.D. student at
>>> Department of Statistical Sciences
>>> University of Bologna, Italy
>>>   
>> --
>> Robin Hankin
>> Uncertainty Analyst and Neutral Theorist,
>> National Oceanography Centre, Southampton
>> European Way, Southampton SO14 3ZH, UK
>>   tel  023-8059-7743
>>
>> __
>> 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] Aliasing a function

[Tony Plate]

Maybe something like this? (though it seems like it might be more 
straightforward to do this sort of thing by text-processing a source 
file then source'ing it in R).

 > f <- function(a, b, c) c(a=a,b=b,c=c)
 > attr(f, "source") <- NULL
 > f
function (a, b, c)
c(a = a, b = b, c = c)
 > g1 <- f
 > ff <- formals(f)
 > argtrans <- c(a="d", b="e", c="f")
 > names(ff) <- argtrans
 > g2 <- as.function(c(ff, as.call(c(list(as.name("f")), 
lapply(argtrans, as.name)
 > g2
function (d, e, f)
f(a = d, b = e, c = f)
 > f(1,2,3)
a b c
1 2 3
 > g1(a=1,b=2,c=3)
a b c
1 2 3
 > g2(d=1,e=2,f=3)
a b c
1 2 3
 >

-- Tony Plate


hadley wickham wrote:
> On Sat, Feb 23, 2008 at 5:52 PM, Gabor Grothendieck
> <[EMAIL PROTECTED]> wrote:
>   
>> I assume he wants to be able to change the
>>  formals although its confusing since the example
>>  uses the same formals in both cases.
>> 
>
> Yes, that was an important point that I forgot to mention!  Thanks for
> the pointer to formals but it doesn't work in this case:
>
> function (a = 1, b = 2, c = 3)
> g(...)
>   
>> f(c=5)
>> 
> Error in f(c = 5) : '...' used in an incorrect context
>
> Hadley
>
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] problem with 'install.packages'

[Tony Plate]

I'm also interested in a solution to this problem of how to update R 
packages without disturbing sessions that may be using them.

For S-PLUS I've been successfully using a system that always creates a 
new directory for an update of a library, eg., there could be multiple 
directories mylib.c0, mylib.c1, mylib.c2, etc.  A single file contains 
the current mapping with lines like "mylib: mylib.c2".  When a new 
library is published, the mapping file is updated.  When a library is 
attached, the custom "attach" function consults the mapping file to find 
the latest version.  This means that different sessions could have 
different versions of the library attached depending on when they 
attached it, and no in-use library will be overwritten.  Obsolete unused 
version of libraries can be cleaned out periodically.

I've been wondering whether "versioned installs" of packages could be 
used to achieve the same goals in R, e.g., with a system to 
automatically bump the third number in the version on each re-install.  
Could this work?  I read that "versioned installs" are not widely used 
and should be used with caution, and notes like "NB: versioned installs 
are not installs of a named package." in ?install.packages make me wary.

-- Tony Plate

Spencer Graves wrote:
> Hi, All: 
>
>   Is there a way to identify whether any users are using a 
> particular package in a shared network R installation? 
>
>   I ask, because we have such a multiple-user installation and when 
> I tried to install a package using Rgui that was in use by Rterm on a 
> single-user installation, 'install.packages' deleted the existing 
> package but failed to install the new version;  see below. 
>
>   I'm concerned especially about the following multiple user 
> scenario:  User A on terminalServer1 tries "install.packages('mvtnorm')" 
> when user B on terminalServer2 was using 'mvtnorm';  both are using the 
> same network installation.  If the results match my experience on a 
> single-user installation, the existing version will be deleted but the 
> new version will NOT be installed.  Any subsequent new attempt to access 
> 'mvtnorm' will fail until all current users of 'mvtnorm' quit those 
> sessions and someone subsequently invokes 
> "install.packages('mvtnorm')".  In fact, user B could have disconnected 
> from that session a month ago, and may have long forgotten the R session 
> that is still officially active, though perhaps consuming 0 CPU seconds 
> in the past month! 
>
>   Thanks,
>   Spencer
> ###
> ##
> ## Rgui
> ##
> ###
> R version 2.6.2 (2008-02-08)
> 
>  > utils:::menuInstallPkgs()
> trying URL 
> 'http://cran.cnr.berkeley.edu/bin/windows/contrib/2.6/mvtnorm_0.8-3.zip'
> Content type 'application/zip' length 214769 bytes (209 Kb)
> opened URL
> downloaded 209 Kb
>
> package 'mvtnorm' successfully unpacked and MD5 sums checked
> Warning: cannot remove prior installation of package 'mvtnorm'
>
> The downloaded packages are in
> C:\Documents and Settings\spencerg\Local 
> Settings\Temp\RtmpghgskA\downloaded_packages
> updating HTML package descriptions
>  > library(mvtnorm)
> Error in library(mvtnorm) : there is no package called 'mvtnorm'
>
>  > sessionInfo()
> R version 2.6.2 (2008-02-08)
> i386-pc-mingw32
>
> locale:
> LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
> States.1252;LC_MONETARY=English_United 
> States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
>
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
>
> loaded via a namespace (and not attached):
> Error in x[["Version"]] : subscript out of bounds
> In addition: Warning message:
> In FUN(c("mvtnorm", "tools")[[2L]], ...) :
>   DESCRIPTION file of package 'mvtnorm' is missing or broken
>  >
> ###
> ##
> ## Concurrent Rterm session
> ##
> ###
> R version 2.6.2 (2008-02-08)
>
> 
>
>  > dmvnorm(1:2)
> [1] 0.01306423
> [1] ".GlobalEnv""package:mvtnorm"   "package:stats"   
>  [4] "package:graphics"  "package:grDevices" "package:utils"   
>  [7] "package:datasets"  "package:methods"   "Autoloads"   
> [10] "package:base"
>  > detach()
>  > dmvnorm(1:2)
> Error: could not find function &qu

[Rd] R_SHARE_DIR not defined for use in tests/Makefile running under Windows

[Tony Plate]

The make variable $(R_SHARE_DIR) seems to be available for use in 
tests/Makefile when running under Linux, but not Windows (R-2.6.2, R-2.6.1, 
R-2.7.0 alpha 2008-04-06, under Windows XP 64 bit, built locally for 32 bit).

Is this intentional, or an oversight?  Is it OK to use $(R_HOME)/share 
instead (seems to work OK)?

I notice the following in /src/gnuwin32/front-ends/rcmdfn.c (from R-alpha 
2008-04-06), which would suggest that the intention was that R_SHARE_DIR 
should be defined... (and I assume it would propagate to to be available in 
a Makefile.)

int rcmdfn (int cmdarg, int argc, char **argv)
{
 /* tasks:
find R_HOME, set as env variable
set R_SHARE_DIR as env variable
set PATH to include R_HOME\bin
set PERL5LIB to %R_SHARE_DIR%/perl;%Perl5LIB%
set TEXINPUTS to %R_SHARE_DIR%/texmf;%TEXINPUTS%
set HOME if unset
launch %R_HOME%\bin\$*
  */

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] R_SHARE_DIR not defined for use in tests/Makefile running under Windows

[Tony Plate]

Ok, thanks for the info.

The reason I'm asking about this is that I'm trying to eliminate reasons for 
having a Makefile.win to accompany a Makefile in the tests directory of a 
package.  I guess I can have /tests/Makefile conditionally set R_SHARE_DIR 
to $(R_HOME)/share if it is undefined.  (aside: where can 
${R_SHARE_DIR-${R_HOME}/share} be used? -- I couldn't get that syntax to do 
anything useful in gnu make v 3.79 from the R toolset for Windows.)

It still seem that src/gnuwin32/front-ends/rcmdfn.c:rcmdfn() is not completing 
the tasks spelled out in the comments at the top of the function:
>> /* tasks:
>>find R_HOME, set as env variable
>>set R_SHARE_DIR as env variable

Further down in rcmdfn() there is the code:
/* currently used by Rd2dvi and by perl Vars.pm (with default) */
strcpy(RSHARE, "R_START_DIR=");
strcat(RSHARE, RHome); strcat(RSHARE, "/share");
putenv(RSHARE);

However, neither $R_HOME/src/scripts/Rd2dvi nor $R_HOME/share/perl/R/Vars.pm 
refer to the env var R_START_DIR, though they do use R_SHARE_DIR (and no other 
files in the entire R source tree apart from rcmdfn.c contain the string 
R_START_DIR, AFAICS).  So, is this just a simple typo of having R_START_DIR 
instead of R_SHARE_DIR in src/gnuwin32/front-ends/rcmdfn.c?

On the topic of make variables vs environment variables, don't variables in the 
environment become make variables?  This is what the gnu make documentation 
says: (http://www.gnu.org/software/make/manual/make.html#Environment)
6.9 Variables from the Environment
... Every environment variable that make sees when it starts up is transformed 
into a make variable with the same name and value...

So, is there any difference between $(X) and ${X} (parenthesis vs braces) in 
variable references in makefiles? I see in a different thread that Prof Brian 
Ripley states (in the context of makefiles) "$(MYVAR) is a make variable, and 
${MYVAR} is an environment variable" ("Problem with Makefile.win and 
environment variable", 2008/03/21), but AFAICS, the gnu make documentation 
suggests these can be used interchangeably 
(http://www.gnu.org/software/make/manual/make.html#Reference).  And, is it ok 
to assume that the 'make' used for running tests will be a "gnu make", or is 
that a dangerous assumption (and the answer to my question above)?

-- Tony Plate



Prof Brian Ripley wrote:
> You seem to be confusing environment and make variables.  I think 
> '$(R_SHARE_DIR)' is never set by R makefiles (except when building R), 
> but may be set by make from an environment variable.
> 
> On all (recentish) systems where the share dir is not ${R_HOME}/share, 
> ${R_SHARE_DIR} is set by the 'R' shell script.  There are such systems 
> -- but not under Windows.
> 
> So ${R_SHARE_DIR-${R_HOME}/share} is the environment variable you want 
> to look at.
> 
> 
> On Mon, 7 Apr 2008, Tony Plate wrote:
> 
>> The make variable $(R_SHARE_DIR) seems to be available for use in
>> tests/Makefile when running under Linux, but not Windows (R-2.6.2, 
>> R-2.6.1,
>> R-2.7.0 alpha 2008-04-06, under Windows XP 64 bit, built locally for 
>> 32 bit).
>>
>> Is this intentional, or an oversight?  Is it OK to use $(R_HOME)/share
>> instead (seems to work OK)?
>>
>> I notice the following in /src/gnuwin32/front-ends/rcmdfn.c (from R-alpha
>> 2008-04-06), which would suggest that the intention was that R_SHARE_DIR
>> should be defined... (and I assume it would propagate to to be 
>> available in
>> a Makefile.)
>>
>> int rcmdfn (int cmdarg, int argc, char **argv)
>> {
>> /* tasks:
>>find R_HOME, set as env variable
>>    set R_SHARE_DIR as env variable
>>set PATH to include R_HOME\bin
>>set PERL5LIB to %R_SHARE_DIR%/perl;%Perl5LIB%
>>set TEXINPUTS to %R_SHARE_DIR%/texmf;%TEXINPUTS%
>>set HOME if unset
>>launch %R_HOME%\bin\$*
>>  */
>>
>> -- Tony Plate
>>
>> __
>> 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] Doing the right amount of copy for large data frames.

[Tony Plate]

Gopi Goswami wrote:
> Hi there,
>
>
> Problem ::
> When one tries to change one or some of the columns of a data.frame, R makes
> a copy of the whole data.frame using the '*tmp*' mechanism (this does not
> happen for components of a list, tracemem( ) on R-2.6.2 says so).
>
>
> Suggested solution ::
> Store the columns of the data.frame as a list inside of an environment slot
> of an S4 class, and define the '[', '[<-' etc. operators using setMethod( )
> and setReplaceMethod( ).
>
>
> Question ::
> This implementation will violate copy on modify principle of R (since
> environments are not copied), but will save a lot of memory. Do you see any
> other obvious problem(s) with the idea?
Well, because it violates the copy-on-modify principle it can 
potentially break code that depends on this principle.  I don't know how 
much there is -- did you try to see if R and recommended packages will 
pass checks with this change in place?
>  Have you seen a related setup
> implemented / considered before (apart from the packages like filehash, ff,
> and database related ones for saving memory)?
>   
I've frequently used a personal package that stores array data in a file 
(like ff).  It works fine, and I partially get around the problem of 
violating the copy-on-modify principle by having a readonly flag in the 
object -- when the flag is set to allow modification I have to be 
careful, but after I set it to readonly I can use it more freely with 
the knowledge that if some function does attempt to modify the object, 
it will stop with an error.

In this particular case, why not just track down why data frame 
modification is copying the entire object and suggest a change so that 
it just copies the column being changed?  (should be possible if list 
modification doesn't copy all components).

-- Tony Plate
>
> Implementation code snippet ::
> ### The S4 class.
> setClass('DataFrame',
>   representation(data = 'data.frame', nrow = 'numeric', ncol =
> 'numeric', store = 'environment'),
>   prototype(data = data.frame( ), nrow = 0, ncol = 0))
>
> setMethod('initialize', 'DataFrame', function(.Object) {
> .Object <- callNextMethod( )
> [EMAIL PROTECTED] <- new.env(hash = TRUE)
> assign('data', as.list([EMAIL PROTECTED]), [EMAIL PROTECTED])
> [EMAIL PROTECTED] <- nrow([EMAIL PROTECTED])
> [EMAIL PROTECTED] <- ncol([EMAIL PROTECTED])
> [EMAIL PROTECTED] <- data.frame( )
> .Object
> })
>
>
> ### Usage:
> nn  <- 10
> ## dd1 below could possibly be created by read.table or scan and data.frame
> dd1 <- data.frame(xx = rnorm(nn), yy = rnorm(nn))
> dd2 <- new('DataFrame', data = dd1)
> rm(dd1)
> ## Now work with dd2
>
>
> Thanks a lot,
> Gopi Goswami.
> PhD, Statistics, 2005
> http://gopi-goswami.net/index.html
>
>   [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] A patch for extending pdf device to embed popup text and web links

[Tony Plate]

Paul Murrell wrote:

Hi


Tobias Verbeke wrote:
  

Dear Tadashi,

Thank you very much for sharing your work.



I am sending a patch for R-2.7.0 for extending pdf device to embed pop
up text and
web links. The patch is available at
http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=R-2.7.0.patch&refer=pdf%20device%20patch
You can see what the patch can do through a sample output, which is available at
http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=sample2.pdf&refer=pdf%20device%20patch
An script is at
http://www.okada.jp.org/RWiki/?plugin=attach&pcmd=open&file=sample2.r&refer=pdf%20device%20patch

Ei-ji Nakama kindly build Windows binary, which can be obtained from
http://prs.ism.ac.jp/~nakama/tadakadosan/cran/
An installer, R-2.7.0pat-win32.exe, will install programs in
C:\Program Files\R\R-2.7.0pat
so that you can use both of original and patched version simultaneously.
  

I think it would be most useful if you could bundle your patched version
of the pdf device in a separate device package, similar to the
RSVGTipsDevice.




I would second that approach, at least in the meantime.  This sort of
functionality is interesting and useful, but needs careful thought to
make it compatible with the existing graphics facilities in R.

One major consideration is that the graphics system tries to be mostly
device-independent, so that R graphics code can be run on any device.
This would need adjustments to the common graphics engine/device C code
rather than just to the C code underlying the PDF device.
  
Yes, more thought about how to integrate standard R graphics with extras 
like popups could be very useful.
I wrote RSVGTipsDevice to be compatible with R graphics, in the sense 
that code that generated a plot on RSVGTipsDevice could generate a plot 
on any device (the information specific to RSVGTipsDevice would just be 
discarded when plotting on other devices.)


I'd love to see more discussion of this, especially if it could lead to 
a more general solution that could be used across multiple formats like 
SVG, PDF, etc, so here's a recap of the issues and approach in 
RSVGTipsDevice.


The features I wanted in RSVGTipsDevice were:
-- a popup "tooltip" on a graphics shape (a title + one or two lines of 
text)

-- a clickable hyperlink on a graphics shape
A difference to the PDF device enhancements being discussed here is that 
RSVGTipsDevice did not support adding any annotations to text.


The challenge in implementing this was that the R graphics commands for 
shapes, like points(), rect(), polygon() etc did not provide any way of 
accepting additional arguments (like tooltiptext= or url=) and passing 
them down to the device-specific graphics functions (written in C).


The approach I took was to provide extra R functions that could be used 
like this:

 setSVGShapeToolTip(title="A triangle", desc1="green", desc2="big")
 setSVGShapeURL("http://www.r-project.org";)
These would set up info for the next graphics shape drawn, saving the 
info in the C level graphics structure for the next call to a shape 
drawing function.  If the next call to points() (or rect(), etc) drew 
multiple shapes, only the first shape would get a tooltip or a 
hyperlink.  This is a definite limitation -- but I couldn't see a good 
way to provide info for multiple shapes (other than by allowing 
vectorized arguments to setSVGShapeToolTip, which seemed sort of 
clunky).  I was hoping for some more discussion about a better way to 
implement this sort of thing in general.  These function calls were made 
"compatible" with any R graphics device by having them check if the 
current device was RSVGTipsDevice -- if it wasn't they would simply 
discard the info.  This means that for code using these function calls 
to run successfully when drawing on other devices, the RSVGTipsDevice 
package must be loaded.


All this was done in a standard R package, so that as Paul says, people 
could try it out without having to recompile R.


These attempts with RSVGTipsDevice (which were features added to the 
RSvgDevice package written by T Jake Luciani) were just a first attempt 
and I'd welcome any discussion or suggestions on how they could be 
better implemented and integrated with R graphics, or integrated with 
similar functionality for other devices.


-- Tony Plate

There is also the issue of following standard R coding style and
semantics.  Rather than your approach of ...

text(5, 2, "text test")
pdf.link.on.text("http://www.google.com";)

... where the second call relies on a global setting to relate to the
appropriate text, it would be better to have something like ...

linkedText(5, 2, "text test", href="http://www.google.com";)

... so that the association is explicit.

By developing your ideas as an add-on package, people can try ou

Re: [Rd] messing with ...

[Tony Plate]

Ben Bolker wrote:


  I'm looking for advice on manipulating parameters that
are going to be passed through to another function.

  Specifically, I am working on my version of "mle",
which is a wrapper for optim (among other optimizers).
I would prefer not to replicate the entire argument
list of optim(), so I'm using ... to pass extra arguments
through.

  However:
the starting values are specified as a list,
which means that users can potentially specify them
in any order (or at least that's the way it works
now -- one solution to the problem I'm about to state
is to insist that they specify the parameters in the
same order as they are given in the arguments of
the objective function).
  However, there are other arguments (lower, upper,
control$parscale, control$ndeps) that should all
be in the same order as the objective function
definition by the time they get to optim()).  I can
think of a few solutions:

 (1) make the user specify them all in the right order (ugh)
 (2) add all of them as explicit parameters to my function
so that I can rearrange them appropriately (ugh)
 (3) mess with the ... argument before it gets passed
through to optim (impossible?)
 (4) capture ... as arglist <- list(...), manipulate the arguments
as necessary, then pass them along to optim as
do.call("optim",arglist) (ugh but maybe the best solution?)

  any thoughts?

here's my two cents:
- require names on parameters, rather than order
- construct calls and use eval() rather than do.call() (then you can 
manipulate list(...) without the ugh factor of do.call() -- though is 
do.call() any different to eval() in R? -- I know in S-PLUS that the use 
of do.call() can completely blow out memory usage)
- to avoid manually duplicating arg lists, use constructs like 
names(formals(optim)) and pmatch to find args that below to the 
optimizer function vs the objective function


-- Tony Plate


 thanks

  Ben Bolker




__
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] dos-style line endings in .Rbuildignore result in files not being excluded

[Tony Plate]

I was trying, on a Linux system, to get a .Rbuildignore file to work.  
After far too long, I found the problem was the  line endings in 
the .Rbuildignore file -- I had originally created it on a Windows 
system, and emacs in Ubuntu was politely hiding that fact from me.  The 
patterns didn't work to exclude files because it was trying to match 
filenames to patterns like "NOTES.txt^M".


I don't know what the best solution to this is, but I got it working by 
putting a substitute command in the bin/build file like this:


   while() {
   chomp;
   s/^M$//;
   push(@exclude_patterns, $_) if $_;

(When I cut and paste that code here it ends up as two separate 
characters ^ and M, but in the bin/build file it's one  character.)


One could of course say it is stupid user error to have 's in the 
.Rbuildignore file, but it can happen easily, and it would nice if R 
would work with it.


Could a fix for this little problem be incorporated into R?

thanks,

Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] dos-style line endings in .Rbuildignore result in files not being excluded

[Tony Plate]

Prof Brian Ripley wrote:

On Tue, 14 Oct 2008, Sebastian P. Luque wrote:


On Mon, 13 Oct 2008 23:10:41 -0600,
Tony Plate <[EMAIL PROTECTED]> wrote:


I was trying, on a Linux system, to get a .Rbuildignore file to work.
After far too long, I found the problem was the  line endings
in the .Rbuildignore file -- I had originally created it on a Windows
system, and emacs in Ubuntu was politely hiding that fact from me.


Are you sure? Whenever I open M$ files in Emacs under Debian I see
'(DOS)' near the left end of the modeline, which indicates that it has
^C as EOL.  This has been the case since at least 21.0.


^M^J, I think you mean (CRLF).

Emacs is not totally consistent about how it does this: since it tries 
to guess the file encoding it will usually indicate (DOS) on the mode 
line, but not always (and it sometimes displays the ^M's, even on 
Windows).


But to the point: how often do people get DOS-style files on a 
Unix-alike? You have to work pretty hard to do this, and there comes a 
point at which complicating R to workaround wrongly encoded files is 
not worth the trouble.  Let's see if anyone else reports having done 
this.


It was pretty easy for me to get these line endings -- I created the 
file in GNU Emacs under Windows, and rsync'ed the package directory to a 
Ubuntu Linux machine.  I went back and checked, and GNU Emacs under 
Ubuntu did show (DOS) in the status line of the buffer, but I never 
noticed that while I was trying to figure out why my .Rbuildignore file 
wasn't having any effect.  (I think I preferred it when Emacs would show 
^M at the end of each line in a CRLF file -- not showing that is what I 
meant by "hiding it from me".)


-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] is.matrix

[Tony Plate]

Daniel Høyer Iversen wrote:

a=c(1,1,2);
is.matrix(a) gives FALSE
is.matrix(t(a)) gives TRUE
is.matrix(t(t(a))) gives TRUE

Is this correct? Shouldn't all give FALSE?
I think is.matrix should give FALSE when dimension is 1*n or n*1.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

  

All of the above is consistent with the documentation for is.matrix():

|  is.matrix| returns |TRUE| if |x| is a matrix and has a |dim 
| attribute of length 2) and |FALSE| otherwise


[There seems to be a typo in this sentence from ?is.matrix : an 
unmatched ")"]


This is also useful behavior -- when programming it is often useful to 
know whether something is a matrix or not because that can affect 
computations performed with the object.


For the more informal definition of "matrix" that it looks like want, 
you could use

is.matrix(x) && all(dim(x)>1)
(or maybe all(dim(x) != 1) depending on how you want to treat matrices 
that have a dimension with zero extent)


-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Package install problem on Windows (PR#13284)

[Tony Plate]

Thanks for the response.

Are the problems with versioned installs fundamental, or are they just a 
case of incomplete implementation and rough edges?

If the latter, would fixes be considered?

I ask because we would find versioned installs very useful in 
maintaining stable production systems, each of which might run with 
different versions of various packages, while making it easy to 
continually develop and refine our packages.  As a point of info, our 
primary use for versioning would be with our own packages, so we could 
probably get away without using versioned installs for base or 
contributed packages.


However, if the problems with versioned installs are not amenable to the 
kinds of fixes that users can contribute, then I guess we should look 
for a different approach.


Suggestions and comments are welcome!  Do many people use versioned 
installs?


-- Tony Plate (coworker of Lars @ blackmesacapital.com)

Prof Brian Ripley wrote:
Installing versioned packages is not supported with namespaces.  I 
have suggested from time to time that versioned installs be removed 
because of this and other known issues, and recommend that you do not 
attempt to use them.


On Thu, 13 Nov 2008, [EMAIL PROTECTED] wrote:


Full_Name: Lars Hansen
Version: 2.8.0
OS: Windows XP Pro x64 SP2
Submission from: (NULL) (71.39.177.36)


Hi,

I have run into a problem using "R CMD INSTALL" with the
"--with-package-versions" option under Windows. It is a bit obscure, 
which could

explain why other people have not run into it.

We happen to have two packages with almost the same name. One name is 
a subset
of the other. The names are "RtTests" and "RtTestsEG1".  I have no 
problem
installing "RtTests" and many other packages, but run into problems 
installing
"RtTestsEG1". The "RtTestsEG1" package happens to be a simple example 
of how to
use the "RtTests" package, so it depends on "RtTests" (which is 
probably the

problem).

OK, so this is what happens when I attempt to install "RtTestsEG1":

$ R CMD INSTALL --with-package-versions --library=$R_LIBS RtTestsEG1

 installing RtTestsEG1 package

-- Making package RtTestsEG1 
 adding build stamp to DESCRIPTION
 installing R files
 preparing package RtTestsEG1 for lazy loading
Loading required package: RtTests
... [lost of lines removed]
Loading required package: RtTests
Error: evaluation nested too deeply: infinite recursion /
options(expressions=)?
Execution halted
make[2]: *** [lazyload] Error 1
make[1]: *** [all] Error 2
make: *** [pkg-RtTestsEG1] Error 2
*** Installation of RtTestsEG1 failed ***

After some digging in the Windows makefiles, I found out that 
changing the

locale from "C" to "us" in the "lazyload" target of
$R_HOME/src/gnuwin32/MakePkg, i.e. using "LC_ALL=us" instead of 
"LC_ALL=C",
solves the infinite recursion problem and give an useful message. It 
still fails

but now says:

Loading required package: RtTests
Warning: S3 methods 'summary.RtTestSetResults', 
'print.RtTestSetResults',
'print.RtTestSetResults.summary' were declared in NAMESPACE but not 
found

Error in namespaceExport(ns, exports) :
 undefined exports: parseTranscriptFile, compareTranscriptAndOutput
Error: package 'RtTests' could not be loaded
Execution halted

It is true that RtTests declares the various functions in its name 
space, but

why can they suddenly not be found? If I load RtTests by itself, i.e.
library(RtTests), there is no problem.

I happen to have all this working under Linux, so I tracked down the 
difference.

Turns out that under Linux the equivalent to the "lazyload" target is in
"/usr/lib/R/bin/INSTALL" and the difference is in the argument passed to
"tools:::makeLazyLoading". Under Linux the full package name with 
version number

is used, i.e. "RtTests_0.1-1". Windows just uses "RtTests".

So I managed to fix the problem by making Windows use the full 
package name in

the "lazyload" target. I replaced
 tools:::makeLazyLoading(\"$(PKG)\"
with
 tools:::makeLazyLoading(\"$(notdir $(DPKG))\"

If I now reinstall "RtTests", I can finally install "RtTestsEG1".

I must confess, that I do not fully understand exactly what it takes to
reproduce this problem. I am guessing that all it takes is a package 
depending
on a versioned package. Maybe the similarity in names introduces a 
problem
because of partial matching. I am guessing that has nothing to do 
with it.


To sum up the report. I see two problems:

1) LC_ALL=C causes infinite recursion. It is as if the C locale does 
not work
under Windows. I do not know what the fix is. It is used many places 
in install
scripts and makefiles. Fixing it in the "lazyload" target is not 
enough. Even
with my change 

Re: [Rd] Package install problem on Windows (PR#13284)

[Tony Plate]

Thanks to Prof Brian Ripley, Martin Maechler, and Simon Urbanek for the 
very informative responses.  It's good to learn that there is a chance 
that versioned installs will go away -- we will avoid using them.


It's also useful to hear of how others create stable package libraries 
while making continual development possible by using different library 
paths, and by dynamically manipulating library paths.  It makes sense 
for us to take a similar approach.


I guess one could take the multiple-library-path approach to the extreme 
of having a single package in each library, with a library for each 
version, e.g., a version 3.1 of package called xyz could be installed in 
library called "xyz_3.1" (so the path of the package would be 
.../xyz_3.1/xyz, and then one would make a call like library("xyz", 
lib.loc=".../xyz_3.1") to get this version.)  This approach could also 
provide a solution to the challenge (under Windows) of installing a new 
version of package into a library without disturbing running R sessions 
that might have that package attached -- by creating a new library for 
the newly installed package, and dynamically finding the latest library 
prior to attaching packages at the beginning of a session.  Are there 
any potential pitfalls to this approach that we should know about?


-- Tony Plate


Martin Maechler wrote:

"SU" == Simon Urbanek <[EMAIL PROTECTED]>
on Thu, 13 Nov 2008 18:47:38 -0500 writes:
    


SU> On Nov 13, 2008, at 6:11 PM, Tony Plate wrote:

>> Thanks for the response.
>> 
>> Are the problems with versioned installs fundamental, or

>> are they just a case of incomplete implementation and
>> rough edges?  If the latter, would fixes be considered?
>> 
>> I ask because we would find versioned installs very

>> useful in maintaining stable production systems, each of
>> which might run with different versions of various
>> packages, while making it easy to continually develop and
>> refine our packages.  As a point of info, our primary use
>> for versioning would be with our own packages, so we
>> could probably get away without using versioned installs
>> for base or contributed packages.
>> 

SU> I find it more useful to work with multiple library paths  
SU> (.libPaths()) than versioning packages in the above

SU> scenario. We usually maintain "stable" package library
SU> which is individually overridden by additional paths
SU> added by the user (e.g. developer library for testing)
SU> and/or subsystems. The override can also be revertive,
SU> i.e. a subsystem is free to use older packages in its
SU> library than the stable library when desired.

We use the same "technique",
both using the R_LIBS environment variable, and also amending it
in an .Rprofile equivalent depending on the version of R (or the
user), i.e., something like

libPIns <- function(nlib, beforeLib, msgTxt) {
  ## Purpose: Insert a directory into .libPaths() *before* another one
  ## 
  ## Arguments: nlib:  The library directory to insert
  ##   beforeLib:  (grep-pattern of an) entry in current .libPaths()
  ##  msgTxt:  optional message text about the insertion
  ## 
  ## Author: Martin Maechler, 2006

  if(file.exists(nlib)) {
if(length({fl <- list.files(nlib); fl[fl != "R.css"]})) {
  ## only if the library contains any packages :
  if(!missing(msgTxt) && is.character(msgTxt))
cat("extending .libPaths()", msgTxt,"...\n")
  ni <- length(iL <- grep(beforeLib, lp <- .libPaths()))
  if(ni != 1) {
warning(".libPaths() contains ",
if(ni>1) "more" else "no",
" entries matching ",sQuote(beforeLib))
iL <- if(ni > 1) iL[1] else length(lp)
cat("Inserting before position", iL,"..\n")
  }
  ii <- 1:length(lp)
  .libPaths(c(lp[ii < iL], nlib, lp[ii >= iL]))
}
  } else warning(nlib, " is not an existing directory")
}

and then somewhere


RVersion <- paste(R.version$major, R.version$minor, sep=".")
Rstat <- R.version$status
is.Rdevel <- ## Rstat == "beta" ||
  length(grep("devel", Rstat)) > 0
if(is.Rdevel)
libPIns(nlib =  file.path(RrootDir,&quo

Re: [Rd] x <- 1:2; dim(x) <- 2? A vector or not?

[Tony Plate]

Martin Maechler wrote:

"PatB" == Patrick Burns 
on Tue, 13 Jan 2009 17:00:40 + writes:



PatB> Henrik Bengtsson wrote:
>> Hi.
>> 
>> On Mon, Jan 12, 2009 at 11:58 PM, Prof Brian Ripley

>>  wrote:
>> 
>>> What you have is a one-dimensional array: they crop up

>>> in R most often from table() in my experience.
>>> 
>>> 
>>>> f <- table(rpois(100, 4)) str(f)
>>>> 
>>> 'table' int [, 1:10] 2 6 18 21 13 16 13 4 3 4 - attr(*,

>>> "dimnames")=List of 1 ..$ : chr [1:10] "0" "1" "2" "3"
>>> ...
>>> 
>>> and yes, f is an atmoic vector and yes, str()'s notation

>>> is confusing here but if it did [1:10] you would not
>>> know it was an array.  I recall discussing this with
>>> Martin Maechler (str's author) last century, and I've
>>> just checked that R 2.0.0 did the same.
>>> 
>>> The place in which one-dimensional arrays differ from

>>> normal vectors is how names are handled: notice that my
>>> example has dimnames not names, and ?names says
>>> 
>>> For a one-dimensional array the 'names' attribute really

>>> is 'dimnames[[1]]'.
>>> 
>> 
>> Thanks for this explanation.  One could then argue that

>> [1:10,] is somewhat better than [,1:10], but that is just polish.

yes.  And honestly I don't remember anymore why I chose the
"[,1:n]" notation.  It definitely was there already before R
came into existence, as  S  also has had one-dimensional arrays,
and I programmed the first version of str() in 1990.

PatB> Perhaps it could be:

PatB> [1:10(,)]

PatB> That is weird enough that it should not lead people to
PatB> believe that it is a matrix.  But might prompt them a
PatB> bit in that direction.

Well, str() was always aimed a bit at experienced S (and R)
users, and I had always aimed somewhat to keep it's output
"compact".  I'm quite astonished that the OP didn't know about
1D arrays in spite of the many years he's been using R.
Would a wierd solution like the above have helped?

At the moment, I'd tend to keep it "as is" if only just for
historical reminescence, but I can be convinced to change the
current "tendency" ... 

Martin Maechler, ETH Zurich  
  

What about just including "(1d-array)", something like this
> str(f)
'table' int [1:10](1d array) 5 5 9 23 26 16 9 4 2 1
- attr(*, "dimnames")=List of 1
 ..$ : chr [1:10] "0" "1" "2" "3" ...
>
only 9 extra characters for a rare case, and much, much less cryptic?

-- Tony Plate



PatB> Patrick Burns patr...@burns-stat.com +44 (0)20 8525
PatB> 0696 http://www.burns-stat.com (home of "The R
PatB> Inferno" and "A Guide for the Unwilling S User")
>> /Henrik
>> 
>> 
>>> I think these days we have enough internal glue in place

>>> that an end user would not notice the difference (but
>>> those working at C level with R objects may need to
>>> know).
>>> 
>>> On Mon, 12 Jan 2009, Henrik Bengtsson wrote:
>>> 
>>> 
>>>> Ran into the follow intermediate case in an external

>>>> package (w/ recent R v2.8.1 patched and R v2.9.0
>>>> devel):
>>>> 
>>>> 
>>>>> x <- 1:2 dim(x) <- 2 dim(x)
>>>>> 
>>>> [1] 2
>>>> 
>>>>> x
>>>>> 
>>>> [1] 1 2
>>>> 
>>>>> str(x)
>>>>> 
>>>> int [, 1:2] 1 2
>>>> 
>>>>> nrow(x)
>>>>> 
>>>> [1] 2
>>>> 
>>>>> ncol(x)
>>>>> 
>>>> [1] NA
>>>> 
>>>>> is.vector(x)
>>>>> 
>>>> [1] FALSE
>>>> 
>>>>> is.matrix(x)
>>>>> 
>>>> [1] FALSE
>>>> 
>>>>> is.array(x)
>>>>> 
>>>> [1] TRUE
>>>> 
>>>>> x[1]
>>>>> 
>>>> [1] 1
>>>> 
>>>>> x[,1]
>>>>> 
>>

Re: [Rd] x <- 1:2; dim(x) <- 2? A vector or not?

[Tony Plate]

Martin Maechler wrote:

"TP" == Tony Plate 
on Fri, 16 Jan 2009 13:10:04 -0700 writes:



TP> Martin Maechler wrote:
>>>>>>> "PatB" == Patrick Burns 
>>>>>>> on Tue, 13 Jan 2009 17:00:40 + writes:
>>>>>>> 
>> 
PatB> Henrik Bengtsson wrote:

>> >> Hi.
>> >> 
>> >> On Mon, Jan 12, 2009 at 11:58 PM, Prof Brian Ripley

>> >>  wrote:
>> >> 
>> >>> What you have is a one-dimensional array: they crop up

>> >>> in R most often from table() in my experience.
>> >>> 
>> >>> 
>> >>>> f <- table(rpois(100, 4)) str(f)
>> >>>> 
>> >>> 'table' int [, 1:10] 2 6 18 21 13 16 13 4 3 4 - attr(*,

>> >>> "dimnames")=List of 1 ..$ : chr [1:10] "0" "1" "2" "3"
>> >>> ...
>> >>> 
>> >>> and yes, f is an atmoic vector and yes, str()'s notation

>> >>> is confusing here but if it did [1:10] you would not
>> >>> know it was an array.  I recall discussing this with
>> >>> Martin Maechler (str's author) last century, and I've
>> >>> just checked that R 2.0.0 did the same.
>> >>> 
>> >>> The place in which one-dimensional arrays differ from

>> >>> normal vectors is how names are handled: notice that my
>> >>> example has dimnames not names, and ?names says
>> >>> 
>> >>> For a one-dimensional array the 'names' attribute really

>> >>> is 'dimnames[[1]]'.
>> >>> 
>> >> 
>> >> Thanks for this explanation.  One could then argue that

>> >> [1:10,] is somewhat better than [,1:10], but that is just polish.
>> 
>> yes.  And honestly I don't remember anymore why I chose the

>> "[,1:n]" notation.  It definitely was there already before R
>> came into existence, as  S  also has had one-dimensional arrays,
>> and I programmed the first version of str() in 1990.
>> 
PatB> Perhaps it could be:
>> 
PatB> [1:10(,)]
>> 
PatB> That is weird enough that it should not lead people to

PatB> believe that it is a matrix.  But might prompt them a
PatB> bit in that direction.
>> 
>> Well, str() was always aimed a bit at experienced S (and R)

>> users, and I had always aimed somewhat to keep it's output
>> "compact".  I'm quite astonished that the OP didn't know about
>> 1D arrays in spite of the many years he's been using R.
>> Would a wierd solution like the above have helped?
>> 
>> At the moment, I'd tend to keep it "as is" if only just for

>> historical reminescence, but I can be convinced to change the
>> current "tendency" ... 
>> 
>> Martin Maechler, ETH Zurich  
>> 
TP> What about just including "(1d-array)", something like this

>> str(f)
TP> 'table' int [1:10](1d array) 5 5 9 23 26 16 9 4 2 1
TP> - attr(*, "dimnames")=List of 1
TP> ..$ : chr [1:10] "0" "1" "2" "3" ...
>> 
TP> only 9 extra characters for a rare case, and much, much less cryptic?


well,.. the next text request is to use
 "character" instead of "chr", only 6 extra characters 

-> no way:  str() has its very concise "style" and should keep
that.
  
Brevity is good, but clarity is important too.   The output of str is 
usually decipherable, but not so much in this case.  It's easy to 
dismiss suggestions like replacing "chr" with "character" - the increase 
in clarity would be minimal.  However, the potential increase in clarity 
for a 1-d array is significant - the decrease in brevity is at question 
here. Given the rarity of the case it seems like a decent tradeoff to 
add "(1d-array)" (one could even just write "(1d)").   1-d arrays are 
sufficiently rare that no concise and clear method of indicating them 
using brackets or other symbols has arisen. You did say you "can be 
convinced to change" it, but I won't attempt beyond this! :-)


best,

Tony Plate

Martin

TP> -- Tony Plate
>> 
>> 
PatB> Patrick Bu

Re: [Rd] overwriting '<-' and infinite recursions

[Tony Plate]

I wonder if you might be able to make use of R's "active bindings."  
These enable you to set things up so that a user definable function is 
called when an assignment is made or when a value is accessed.  It's 
sort of like overriding assignment for a particular variable, but you 
don't need to mess with the definition of assignment.


Do
> apropos("binding")
to see the related functions.  The help page for makeActiveBinding has a 
simple example.


-- Tony Plte

Yi Zhang wrote:

Thanks, Luke. I would certainly be very happy to see any non-intrusive
solution. The problem I'm dealing with is: I'm creating a new class
which references some external resource (file or database) and I want
to make the reference counting work. An example (-> means references):
Initially we have symbol a -> object oa of my class -> file fa.
Suppose then R code "b<-a" is executed. With no modification to the
'<-' function, R would make another symbol b and bind it to oa.
Imagine next "b[1]<-0" is executed. Here comes the trouble: R only
knows to duplicate oa to another ob; the modification will be done to
the underlying shared file fa. Of course, I have necessary code for
overriding "[<-" and make that modification. The whole thing is
because I'm not aware of any sharing of the external resource at the R
level. That's the motivation for me to
overwrite '<-' in the first place. Any potential alternative solutions?

On Fri, Jan 23, 2009 at 4:25 PM,   wrote:
  

While it _may_ be possible to make this work in current R (I don't
know if it is) this is a Really Bad Idea as it will affect every other
piece of R code run on the system. It also may not work at all in
future versions of R (assignment is sufficiently core functionality
that it may not be implemented via a function at all in some
circumstances).  Locked bindings are locked for a reason: we as
developers can assume that their values are what we intend them to be.
If those values are changed then that assumption fails and some things
may stop working.

If you explain what your needs are someone on the list can probably
help you find a more effective and less intrusive way of doing it.

luke


On Fri, 23 Jan 2009, Yi Zhang wrote:



Hello all,

I'm having a problem when overwriting the '<-' function and was told
I'd better post it here for help. The reason why I need to overwrite
it is complicated and not easy to tell in a few words; but this seems
the only clean option other than hacking R's core source code. My code
looks like:

# in .onLoad of a package; or if you want to test, put it in a function
env <- as.environment('package:base')
unlockBinding('<-',env)
assign('<-', newAssign, envir=env)
.Internal(lockBinding(as.name('<-'), env))
#not using lockBinding directly because it calls '<-'

It gave me this error: Error: evaluation nested too deeply: infinite
recursion / options(expressions=)?

Any suggestion is appreciated!

--
Yi

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

  

--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
  Actuarial Science
241 Schaeffer Hall  email:  l...@stat.uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu









__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] (PR#13487) Segfault when mistakenly calling [.data.frame

[Tony Plate]

Simon Urbanek wrote:


On Jan 30, 2009, at 10:30 , Christian Brechbühler wrote:

On Thu, Jan 29, 2009 at 4:44 PM, Prof Brian Ripley 
wrote:


What did your actual application do?  This seems a very strange 
thing to

do, and the segfault is in trying to construct the traceback.

Only by using do.call on the object (and not even by name) do I get 
this

error.  E.g.

`[.data.frame`(1:10, 3)



Error in NextMethod("[") : object not specified


do.call("[.data.frame", list(1:10, 3))


Error in NextMethod("[") : object not specified

are fine.

Obviously it would be nice to fix this, but I'd like to understand the
actual circumstances: there is more to it than the subject line.



Yes, there is more.  For reporting the problem, we tried to pare it 
down to

a concise, self-contained test case.

My boss was debugging an issue in our R code.  We have our own "["
functions, because stock R drops names when subscripting.


... if you tell it to do so, yes. If you tell it to not do that, it 
won't ... ever tried drop=FALSE ?
The common situation I have (which might be the same as the OP's) is 
wanting to get a vector from a data frame, and having the rownames of 
the dataframe become the names on the vector.


With matrix, the behavior I want is the default behavior, e.g.,
> x <- cbind(a=c(x=1,y=2,z=3),b=4:6)
> x
 a b
x 1 4
y 2 5
z 3 6
> x[,1]
x y z
1 2 3

But with a data frame, subscripting returns a vector with no names:
> xd <- as.data.frame(x)
> xd[,1]
[1] 1 2 3

One can use drop=FALSE, but then you've still got a data frame, not a 
vector:

> (xd1 <- xd[,1,drop=FALSE])
 a
x 1
y 2
z 3

The simplest way I know to get a named vector is to use as.matrix on the 
one-column dataframe:

> as.matrix(xd1)[,1]
x y z
1 2 3
>
(Which works fine except in the case where xd1 has only one row...)

And BTW, am I missing something, or does the behavior of drop() not 
conform to the description in ?drop:

> Value:
> If 'x' is an object with a 'dim' attribute (e.g., a matrix or
> 'array'), then 'drop' returns an object like 'x', but with any
> extents of length one removed.  Any accompanying 'dimnames'
> attribute is adjusted and returned with 'x': if the result is a
> vector the 'names' are taken from the 'dimnames' (if any).  If the
> result is a length-one vector, the names are taken from the first
> dimension with a dimname.

How is this last sentence consistent with the following behavior?
> dimnames(x[1,1,drop=F])
[[1]]
[1] "x"

[[2]]
[1] "a"

> drop(x[1,1,drop=F])
[1] 1
>
From the description in "Value:" in ?drop, I would have expected above 
result to have the name "x" (the name from the first dimension with a 
dimname).


> sessionInfo()
R version 2.8.1 (2008-12-22)
i386-pc-mingw32

locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United 
States.1252;LC_MONETARY=English_United 
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252


attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base
>


-- Tony Plate


Cheers,
S



To bypass our
now-suspect functions and get the "real" subscripting method, he used 
"get"
from package:base.  He was examining a large object, and believing it 
was a
data frame, chose "[.data.frame".  As it turns out, that object was 
not a

data frame, and he got an unexpected segfault.  I think it was a matrix.
But it doesn't matter -- a vector as in the test case will give the 
same.


We have since fixed the bug in our replacement subscripting function, 
so the

issue might not affect us any more.

Thanks,
/Christian



On Thu, 29 Jan 2009, brechbueh...@gmail.com wrote:

Full_Name: Christian Brechbuehler

Version: 2.7.2, 2.8.1
OS: linux-gnu

If we mistakenly believe the object is a data frame (as we did in a 
much

more
complicated real situation), this happens:


do.call(get("[.data.frame",pos="package:base"),list(1:10,3))

Error in NextMethod("[") :
  no calling generic was found: was a method called directly?

 *** caught segfault ***
address (nil), cause 'unknown'

Process R:2 segmentation fault (core dumped) at Thu Jan 29 09:26:29 
2009


The Error message is appropriate.  But the segmentation fault is
unexpected.





[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] surprising behaviour of names<-

[Tony Plate]

Wacek Kusnierczyk wrote:

[snip]
i just can't get it why the manual does not manifestly explain what
'names<-' does, and leaves you doing the guesswork you suggest.

  
I'm having trouble understanding the point of this discussion.  Someone 
is calling a replacement function in a way that it's not meant to be 
used, and is them complaining about it not doing what he thinks it 
should, or about the documentation not describing what happens when one 
does that?


Is there anything incorrect or missing in the help page for normal usage 
of the replacement function for 'names'? (i.e., when used in an 
expression like 'names(x) <- ...')


R does give one the ability to use its facilities in non-standard ways.  
However, I don't see much value in the help page for 'gun' attempting to 
describe the ways in which the bones in your foot will be shattered 
should you choose to point the gun at your foot and pull the trigger.  
Reminds me of the story of the guy in New York, who after injuring his 
back in refrigerator-carrying race, sued the manufacturer of the 
refrigerator for not having a warning label against that sort of use.


-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] surprising behaviour of names<-

[Tony Plate]

Wacek Kusnierczyk wrote:

Tony Plate wrote:
  

Wacek Kusnierczyk wrote:


[snip]
i just can't get it why the manual does not manifestly explain what
'names<-' does, and leaves you doing the guesswork you suggest.

  
  
I'm having trouble understanding the point of this discussion. 
Someone is calling a replacement function in a way that it's not meant

to be used, and is them complaining about it not doing what he thinks
it should, or about the documentation not describing what happens when
one does that?



where is it written that the function is not meant to be used this way? 
you get an example in the man page, showing precisely how it could be

used that way.  it also explains the value of 'names<-':

"
 For 'names<-', the updated object.  (Note that the value of
 'names(x) <- value' is that of the assignment, 'value', not the
 return value from the left-hand side.)
"

it does speak of 'names<-' used in prefix form, and does not do it in
any negative (discouraging) way.

  

Is there anything incorrect or missing in the help page for normal
usage of the replacement function for 'names'? (i.e., when used in an
expression like 'names(x) <- ...')



what is missing here in the first place is a specification of what
'normal' means.  as far as i can see from the man page, 'normal' does
not exclude prefix use.  and if so, what is missing in the help page is
a clear statement what an application of 'names<-' will do, in the sense
of what a user may observe.
  
Fair enough.  I looked at the help page for "names" after sending my 
email, and was surprised to see the following in the "DETAILS" section:


  "It is possible to update just part of the names attribute via the 
general rules: see the examples. This works because the expression there 
is evaluated as |z <- "names<-"(z, "[<-"(names(z), 3, "c2"))|. "


To me, this paragraph is far more confusing than enlightening, 
especially as also gives the impression that it's OK to use a 
replacement function in a functional form.  In my own personal opinion 
it would be a enhancement to remove that example from the documentation, 
and just say you can do things like 'names(x)[2:3] <- c("a","b")'.


I often use name replacement functions in a functional way, and because 
one can't use 'names<-' etc in this way, I define my own functions like 
the following:


set.names <- function(n,x) {names(x) <- n; x}

(and similarly for set.rownames(), set colnames(), etc.)

I would highly recommend you do this rather than try to use a call like 
"names<-"(x, ...).


-- Tony Plate

(I guess that if on the label of fridge there is a picture of a guy 
carrying it on his back, then Mr. Fridge-Racer might have some grounds 
for suing.)


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] how to add a target to the Make that R CMD check uses for running tests?

[Tony Plate]

I'd like to have some additional 'make' targets for tests that are run in /tests by 
"R CMD check" (to do things like run tests with different pre-processing and 
post-processing, generate test summaries, etc.)

Is there a good way to do this?  At the moment I make 'make' jump through 
hoops, and it works, but I'd like to find a better way.

A method I used initially was to change the default goal by assigning .DEFAULT_GOAL in 
tests/Makefile.  This works nicely with GNU make version 3.81, which is standard in 
Ubuntu Linux.  However, the Rtools set of programs for Windows (as of R 2.6.2) includes 
GNU make version 3.79, which does not appear to recognize .DEFAULT_GOAL.  Additionally, 
version 2.6.2 (2008-02-08) of "R Installation and Administration" specifically 
says that GNU make version 3.81 does not work to compile R under Windows. Furthermore, 
Mac OS X version 10.4 (Tiger) includes GNU make version 3.80, which also does not appear 
to recognize the .DEFAULT_GOAL special variable.  So, that method appears to not be 
portable (though things might have changed since I last investigated a year ago.)

After searching around and various experiments, I came up with the following 
ugly hack where I include the following code in tests/Makefile:

# Use 'force targets' to effectively create another target, by calling
# make recursively with the target 'all-Rt'.  See here for 'force targets':
# http://www.gnu.org/software/automake/manual/make/Force-Targets.html
# Based on code at
# http://www.gnu.org/software/automake/manual/make/Overriding-Makefiles.html
# but with more levels of protection to avoid calling make with
# the target 'all-Rt' more than once, because this makefile is
# read many times.  Condition on DONEFORCE being not defined
# to avoid infinite recursion.
ifeq ($(strip $(DONEFORCE)),)
%: force
@(if [ ! -f forceonce ] ; then \
$(MAKE) -f $(R_SHARE_DIR)/make/$(RSHAREMAKEFILE) $(makevars) -f 
$(MAINTESTMAKE) DONEFORCE=TRUE all-Rt ; \
fi )
@touch forceonce

force: ;
endif

This code causes 'make' to be called just once with the target 'all-Rt', using 
appropriate settings for RSHAREMAKEFILE (either 'tests.mk' or 'wintests.mk') 
and MAINTESTMAKE (either 'Makefile' or 'Makefile.win') (There are set in other 
parts of the Makefile).

The above code runs as intended under Linux, Windows, and Mac OS X, at least on 
the installations I've tested.

However this technique is ugly.  There must be a better way.  Any suggestions? 
(I guess I could probably get rid of the 'forceonce' protection pretty easily, 
but the $(DONEFORCE) protection seems harder to get rid of, and I'd like to 
think there must be an easier way of adding a target anyway.)

-- Tony Plate

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] 'is.integer' (PR#13671)

[Tony Plate]

is.integer() is one of those functions with a name that can be confusing 
-- it looks at the underlying storage type of its argument (e.g., 
integer, floating point, character, etc.) not at the value stored in the 
argument.


So, the type of behavior you see is this:

> is.integer(1)
[1] FALSE
> is.integer(as.integer(1))
[1] TRUE
> is.integer(as.integer(1) * 1.0)
[1] FALSE
> is.integer(as.integer(NA))
[1] TRUE
>

Careful reading of ?is.integer does tell you this, but I wouldn't accuse 
that help page of making such information blatantly obvious to new users 
of R.


To test whether a value is an integer value, you can so something like this:

> is.wholenumber <- function(x, tolerance = .Machine$double.eps^0.5) 
return(abs(x - round(x)) < tolerance)

> is.wholenumber(1)
[1] TRUE
> is.wholenumber(seq(1,5,by=0.5))
[1]  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE
>

The 'tolerance' part is to allow for minor deviations that might be due 
to floating point representation issues, e.g., on my computer 1/49 * 49 
does not result in a value that is exactly equal to 1:


> 1/49 * 49 - 1
[1] -1.110223e-16
> is.wholenumber(1/49 * 49)
[1] TRUE
> is.wholenumber(1/49 * 49, tol=0)
[1] FALSE
>

-- Tony Plate

hzambran.newsgro...@gmail.com wrote:

Full_Name: Mauricio
Version: 2.9.0 (2009-04-17)
OS:  i486-pc-linux-gnu
Submission from: (NULL) (193.205.203.3)


This is a very simple function that seems not to be working, according to the
definition given by '?is.integer'.

I checked in the Bug Tracking page at http://bugs.R-project.org/, but I didn't
find any related message.

The possible problem is:


  

is.integer(1)


[1] FALSE

and 1 is obviously an integer value.


I would really appreciate if you could clarify if this is really a bug or not.

Thanks in advance,

Mauricio

  

version

   _   
platform   i486-pc-linux-gnu   
arch   i486
os linux-gnu   
system i486, linux-gnu 
status 
major  2   
minor  9.0 
year   2009
month  04  
day17  
svn rev48333   
language   R   
version.string R version 2.9.0 (2009-04-17)


__
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