[Rd] typo in R FAQ: sources.list entry for debian 'stable' backports
The R FAQ at http://cran.r-project.org/doc/FAQ/R-FAQ.html#Are-there-Unix-binaries-for-R_003f advises the use of the following /etc/apt/sources.list entry deb http://cran.R-project.org/bin/linux/debian stable . I think that this is missing a forward slash after the word 'stable'. >From man sources.list: [...] distribution can specify an exact path, in which case the components must be omitted and distribution must end with a slash (/) [...] And empirically: dd:/home/dan# cat /etc/apt/sources.list deb http://cran.R-project.org/bin/linux/debian stable dd:/home/dan# apt-get update E: Malformed line 1 in source list /etc/apt/sources.list (dist parse) versus dd:/home/dan# cat /etc/apt/sources.list deb http://cran.R-project.org/bin/linux/debian stable/ dd:/home/dan# apt-get update Get:1 http://cran.R-project.org stable/ Packages [3155B] Get:2 http://cran.R-project.org stable/ Release [71B] Fetched 3226B in 0s (5206B/s) Reading Package Lists... Done Dan p.s. Thanks for the help I received this week as a result of not reading the FAQ... __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] drop() and "["(), and apply()
I have two queries about the behaviour of drop() and apply() regarding the dimnames and names(dimnames) of the answer. I would appreciate any comments on this behaviour. I will submit any of this as a bug report if I am encouraged to do so. The first query, concerning drop(), seems to me to be a bug in ?drop, and possibly also in the function. ?drop: [...] Any accompanying 'dimnames' attribute is adjusted and returned with 'x'. > x <- array(dim=c(3,2,1), dimnames=list(A=NULL, B=NULL, C=NULL)) > attributes(drop(x)) $dim [1] 3 2 > attributes(x[,,]) $dim [1] 3 2 I expected a dimnames attribute equivalent to list(A=NULL, B=NULL). I think ?drop is misleading. Is the behaviour intended? ### I am less confident that the second query, concerning apply(), is a bug in anything. But I would appreciate an explanation of the behaviour. > x <- array(dim=c(3,2), dimnames=list(A=1:3, B=1:2)) > apply(x, 1, function(row) row) A 1 2 3 1 NA NA NA 2 NA NA NA > attributes(apply(x, 1, function(row) row)) $dim [1] 2 3 $dimnames $dimnames[[1]] [1] "1" "2" $dimnames$A [1] "1" "2" "3" What has happened to the name of the first element of the list of dimnames of the answer? It seems arguable that if the rows of the answer are allowed to keep their names, then the name of that dimension should also be preserved. Should the behaviour be better documented in ?apply (which only discusses the effect on the dim attribute AFAICS). Thanks for any comments. Please let me know if I should submit any bug reports concerning any of the above. Dan > version _ platform i386-pc-linux-gnu arch i386 os linux-gnu system i386, linux-gnu status major2 minor2.0 year 2005 month10 day 06 svn rev 35749 language R Debian linux [EMAIL PROTECTED]:~$ uname -a Linux dd.princeton.edu 2.6.6 #1 SMP Fri Jul 16 13:23:04 EDT 2004 i686 GNU/Linux __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] possible bug in 'scan'
Hi Ben,
On Tue, Jun 26, 2007 at 11:58:35AM -0400, Benjamin Tyner wrote:
> R-devel,
>
> When I run the following code on the attached file,
>
> tmp <- scan("C:/temp.csv",
>what=list("character","numeric"),
>sep=",")
>
> Then tmp[[2]] is a character vector. My impression from the help file
> is that it should be a numeric as specified by 'what'
?scan says
[...]
what: the type of 'what' gives the type of data to be read.
[...]
so for example
what=list(character(), numeric())
would presumably have worked, but not your code, as both of your list elements
are of type character.
Dan
>
> >sessionInfo()
> R version 2.5.0 (2007-04-23)
> 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:
> latticegdata
> "0.15-5" "2.3.1"
>
> My apologies if this is due to my misunderstanding.
> 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
[Rd] ?eigen documentation suggestion
from ?eigen symmetric: if 'TRUE', the matrix is assumed to be symmetric (or Hermitian if complex) and only its lower triangle is used. If 'symmetric' is not specified, the matrix is inspected for symmetry. I think that could mislead a naive reader as it suggests that, with symmetric=TRUE, the result of eigen() (vectors and values) depends only on the lower-triangular values, and thus not on the values on the diagonal (that's not true for the eigenvalues). I suggest that changing it to "... and only its lower triangle is used when computing the eigenvectors." would be more accurate, perhaps even with a reminder about the trace - sum of eigenvalues relationship. Dan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rscript argument processing minor bug with -g
I think there's a minor bug in the argument-processing carried out by Rscript. The effect is that if one passes "-g" as a flag to the script, it is erroneously exposed to the main executable's argument processing and therefore generates a message about not being able to comply with the request for a particular GUI. Uppercase G is fine as are the other 25 letters in upper or lower case. I noticed this with R-2.5.1 and carried out the tests below with R-devel-2.7.0. Dan platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Under development (unstable) major 2 minor 7.0 year 2008 month 01 day04 svn rev43862 language R version.string R version 2.7.0 Under development (unstable) (2008-01-04 r43862) [fedora core 5] ## No problem with -a -b -f -h ~/src/scripts/R> /usr/src/R/R-devel/bin/Rscript -e "commandArgs()" -a -b -f -h [1] "/usr/src/R/R-devel/bin/exec/R" "--slave" [3] "--no-restore" "-e" [5] "commandArgs()" "--args" [7] "-a""-b" [9] "-f""-h" ## But if -g is in there, there's a warning message ~/src/scripts/R> /usr/src/R/R-devel/bin/Rscript -e "commandArgs()" -a -b -f -g -h WARNING: unknown gui '-h', using X11 [1] "/usr/src/R/R-devel/bin/exec/R" "--slave" [3] "--no-restore" "-e" [5] "commandArgs()" "--args" [7] "-a""-b" [9] "-f""-g" [11] "-h" ~/src/scripts/R> /usr/src/R/R-devel/bin/Rscript -e "commandArgs()" -a -b -f -g not_a_gui -h WARNING: unknown gui 'not_a_gui', using X11 [1] "/usr/src/R/R-devel/bin/exec/R" "--slave" [3] "--no-restore" "-e" [5] "commandArgs()" "--args" [7] "-a""-b" [9] "-f""-g" [11] "not_a_gui" "-h" ## The problem remains if the R code is in a file rather than in-line, ## and also with a #! style script: ~/src/scripts/R> cat test.R #!/usr/src/R/R-devel/bin/Rscript commandArgs() ~/src/scripts/R> ./test.R -a -g invalid_gui WARNING: unknown gui 'invalid_gui', using X11 [1] "/usr/src/R/R-devel/bin/exec/R" "--slave" [3] "--no-restore" "--file=./test.R" [5] "--args""-a" [7] "-g""invalid_gui" ~/src/scripts/R> cat test2.R commandArgs() ~/src/scripts/R> /usr/src/R/R-devel/bin/Rscript test2.R -a -g WARNING: --gui or -g without value ignored [1] "/usr/src/R/R-devel/bin/exec/R" "--slave" [3] "--no-restore" "--file=test2.R" [5] "--args""-a" [7] "-g" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] assigning NULLs to elements of a list
On Tue, Feb 12, 2008 at 11:06:59AM +, Oleg Sklyar wrote: > Dear developers: > > I have just came across an (unexpected to me) behaviour of lists when > assigning NULLs to list elements. I understand that a NULL is a valid R > object, thus assigning a NULL to a list element should yield exactly the > same result as assigning any other object. So I was surprised when > assigning a NULL in fact removed the element from the list. Is this an > intended behaviour? If so, does anybody know where is it documented and > what is a good way around? > > Thanks for help, > Oleg Sklyar > > Here goes an example, the inline C-code does exactly what I would prefer > R were doing, but both R examples do remove the element 'b': > > x = list(a=c(1L,2L), b=matrix(runif(4),2,2), c=LETTERS[1:3]) > > library(inline) > code=" >SEXP res; >PROTECT(res = Rf_duplicate(x)); >SET_VECTOR_ELT(res,1,R_NilValue); >UNPROTECT(1); >return res; > " > setnull = cfunction(signature(x="list"),code) > setnull(x) > > # $a > # [1] 1 2 > # $b > # NULL > # $c > # [1] "A" "B" "C" > > y = x > x[[2]] = NULL Hi Oleg, To do this I use x[2] <- list(NULL) In particular I do this when constructing lists to act as the 'what' argument for scan(), where a NULL element means that the column should be skipped, whereas obviously a non-existent element won't serve that purpose. I would be interested to hear whether this is the 'proper' way to construct such lists. Dan > x > # $a > # [1] 1 2 > # $c > # [1] "A" "B" "C" > > x = y > x$b = NULL > x > # $a > # [1] 1 2 > # $c > # [1] "A" "B" "C" > > > sessionInfo() > R version 2.6.1 (2007-11-26) > i686-pc-linux-gnu > > locale: > LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] inline_0.3.3 > > loaded via a namespace (and not attached): > [1] rcompgen_0.1-17 > > > -- > Dr Oleg Sklyar * EBI-EMBL, Cambridge CB10 1SD, UK * +44-1223-494466 > > __ > 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] allow NAs in upper tri for eigen(x,symmetric=TRUE)?
Thanks for acting on my original quibble; I had never questioned whether the
diagonal
was part of the lower triangle. However, I'm afraid I now have another related
quibble.
Seeing as ?eigen says that if(symmetric) 'only its lower triangle is used',
it's seems a
bit unfair of it to complain when there are NAs in the upper triangle. For
example, when
computing a covariance/distance matrix between a large number of individuals,
one might
be tempted to only compute the lower.tri values and leave the upper.tri NA.
Do you see any justification for changing eigen() along the lines of
will.use <- if(symmetric) lower.tri(x, diag=TRUE) else TRUE
if (any(!is.finite(x[will.use])))
stop("infinite or missing values in 'x'")
?
Thanks,
Dan
On Thu, Nov 29, 2007 at 05:46:38PM +0100, Martin Maechler wrote:
> >>>>> "DD" == Dan Davison <[EMAIL PROTECTED]>
> >>>>> on Thu, 29 Nov 2007 11:34:18 + writes:
>
> DD> from ?eigen
> DD> symmetric: if 'TRUE', the matrix is assumed to be symmetric (or
> DD> Hermitian if complex) and only its lower triangle is used. If
> DD> 'symmetric' is not specified, the matrix is inspected for
> DD> symmetry.
>
>
> DD> I think that could mislead a naive reader as it suggests that, with
> symmetric=TRUE,
> DD> the result of eigen() (vectors and values) depends only on the
> lower-triangular values,
> DD> and thus not on the values on the diagonal (that's not true for the
> eigenvalues).
>
> Well, that all depends on what you think when you read
> "lower triangle".
>
> For many of us, this can include the diagonal or not, and we
> don't know if it is not specified further.
>
> ?lower.tri -- shows the option to include the diagonal.
>
> Consequently, I'd suggest to replace
>
>"only its lower triangle is used"
> with "only its lower triangle (diagonal included) is used"
>
> Martin Maechler, ETH Zurich
>
> DD> I suggest that changing it to
>
> DD> "... and only its lower triangle is used when computing the
> eigenvectors."
>
> DD> would be more accurate, perhaps even with a reminder about the trace
> - sum of eigenvalues
> DD> relationship.
>
> DD> Dan
>
> DD> __
> DD> R-devel@r-project.org mailing list
> DD> 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] HOW TO AVOID LOOPS
On Sat, Apr 12, 2008 at 01:30:13PM -0400, Vincent Goulet wrote:
> Le sam. 12 avr. à 12:47, carlos martinez a écrit :
> >> Looking for a simple, effective a minimum execution time solution.
> >>
> >> For a vector as:
> >>
> >> c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
> >>
> > To transform it to the following vector without using any loops:
> >
> >> (0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6)
> >>
> > Appreciate any suggetions.
>
> This does it -- but it is admittedly ugly:
>
> > x <- c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
> > ind <- which(x == 0)
> > unlist(lapply(mapply(seq, ind, c(tail(ind, -1) - 1, length(x))),
> function(y) cumsum(x[y])))
> [1] 0 0 1 0 1 2 3 0 0 1 2 0 1 0 1 2 3 4 5 6
>
> (The mapply() part is used to create the indexes of each sequence in x
> starting with a 0. The rest is then straightforward.)
Here's my effort. Maybe a bit easier to digest? Only one *apply so probably
more efficient.
function(x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)) {
d <- diff(c(0,x,0))
starts <- which(d == 1)
ends <- which(d == -1)
x[x == 1] <- unlist(lapply(ends - starts, function(n) 1:n))
x
}
Dan
>
> HTH
>
> ---
>Vincent Goulet, Associate Professor
>École d'actuariat
>Université Laval, Québec
>[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
>
> __
> 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] HOW TO AVOID LOOPS
On Sat, Apr 12, 2008 at 06:45:00PM +0100, Dan Davison wrote:
> On Sat, Apr 12, 2008 at 01:30:13PM -0400, Vincent Goulet wrote:
> > Le sam. 12 avr. à 12:47, carlos martinez a écrit :
> > >> Looking for a simple, effective a minimum execution time solution.
> > >>
> > >> For a vector as:
> > >>
> > >> c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
> > >>
> > > To transform it to the following vector without using any loops:
> > >
> > >> (0,0,1,0,1,2,3,0,0,1,2,0,1,0,1,2,3,4,5,6)
> > >>
> > > Appreciate any suggetions.
> >
> > This does it -- but it is admittedly ugly:
> >
> > > x <- c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)
> > > ind <- which(x == 0)
> > > unlist(lapply(mapply(seq, ind, c(tail(ind, -1) - 1, length(x))),
> > function(y) cumsum(x[y])))
> > [1] 0 0 1 0 1 2 3 0 0 1 2 0 1 0 1 2 3 4 5 6
> >
> > (The mapply() part is used to create the indexes of each sequence in x
> > starting with a 0. The rest is then straightforward.)
>
>
> Here's my effort. Maybe a bit easier to digest? Only one *apply so probably
> more efficient.
>
> function(x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)) {
> d <- diff(c(0,x,0))
> starts <- which(d == 1)
> ends <- which(d == -1)
> x[x == 1] <- unlist(lapply(ends - starts, function(n) 1:n))
> x
> }
>
Come to think of it, I suggest using the existing R function rle(), rather than
my dodgy substitute.
e.g.
g <- function(x=c(0,0,1,0,1,1,1,0,0,1,1,0,1,0,1,1,1,1,1,1)) {
runs <- rle(x)
runlengths <- runs$lengths[runs$values == 1]
x[x == 1] <- unlist(lapply(runlengths, function(n) 1:n))
x
}
Dan
p.s. R-help would perhaps have been more appropriate than R-devel
> Dan
>
>
> >
> > HTH
> >
> > ---
> >Vincent Goulet, Associate Professor
> >École d'actuariat
> >Université Laval, Québec
> >[EMAIL PROTECTED] http://vgoulet.act.ulaval.ca
> >
> > __
> > 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] relist.Rd patch
There are a few typos in the documentation for relist(). I've also
made a few other changes to the file which I believe are
improvements. I've attached a patch against the version under the
'trunk' branch on the svn server checked out today. It was produced by
diff -u /usr/local/src/R/R-svn-trunk/src/library/utils/man/relist.Rd
~/relist-new.Rd
I'd also suggest identical() rather than "==" in the equalities at the
bottom of the documentation, but that may be overly pedantic.
Dan
--
www.stats.ox.ac.uk/~davison
--- /usr/local/src/R/R-svn-trunk/src/library/utils/man/relist.Rd
2008-08-16 13:41:50.0 +0100
+++ /home/dan/relist-new.Rd 2008-08-16 17:15:54.0 +0100
@@ -13,7 +13,7 @@
\alias{is.relistable}
\alias{unlist.relistable}
%
-\title{Allow Re-Listing an unlisted() Object}
+\title{Allow Re-Listing an unlisted Object}
\description{
\code{relist()} is an S3 generic function with a few methods in order
to allow easy inversion of \code{\link{unlist}(obj)} when that is used
@@ -33,8 +33,9 @@
}
\arguments{
- \item{flesh}{ .}
- \item{skeleton}{ .}
+ \item{flesh}{a vector to be relisted}
+ \item{skeleton}{a list, the structure of which determines the structure
+ of the result}
\item{x}{an \R object, typically a list (or vector).}
\item{recursive}{logical. Should unlisting be applied to list
components of \code{x}?}
@@ -42,13 +43,13 @@
}
\details{
Some functions need many parameters, which are most easily represented in
- complex structures. Unfortunately, many mathematical functions in \R,
+ nested list structures. Unfortunately, many mathematical functions in \R,
including \code{\link{optim}} and \code{\link{nlm}} can only operate on
functions whose domain is
- a vector. \R has \code{\link{unlist}()} to convert complex objects into a
- vector representation. \code{relist()}, it's methods and the
+ a vector. \R has \code{\link{unlist}()} to convert nested list objects into
a
+ vector representation. \code{relist()}, its methods, and the
functionality mentioned here provide the inverse operation to convert
- vectors back to the convenient structural representation.
+ vectors back to the convenient structured representation.
This allows structured functions (such as \code{optim()}) to have simple
mathematical interfaces.
@@ -60,7 +61,9 @@
list(mean=c(0, 1), vcov=cbind(c(1, 1), c(1, 0))).
}
However, \code{\link{optim}} cannot operate on functions that take lists as
input; it
- only likes numeric vectors. The solution is conversion:
+ only likes numeric vectors. The solution is conversion. Given a
+ function mvdnorm(x, mean, vcov, log=FALSE) which computes the required
+ probability density, then
\preformatted{
ipar <- list(mean=c(0, 1), vcov=cbind(c(1, 1), c(1, 0)))
initial.param <- as.relistable(ipar)
@@ -68,9 +71,8 @@
ll <- function(param.vector)
{
param <- relist(param.vector)
- -sum(dnorm(x, mean = param$mean, vcov = param$vcov,
+ -sum(mvdnorm(x, mean = param$mean, vcov = param$vcov,
log = TRUE))
- ## NB: dnorm() has no vcov... you should get the point
}
optim(unlist(initial.param), ll)
@@ -83,14 +85,14 @@
}
will put the content of flesh on the skeleton. You don't need to specify
skeleton explicitly if the skeleton is stored as an attribute inside flesh.
- In particular, flesh was created from some object obj with
+ In particular, if flesh was created from some object obj with
\code{unlist(as.relistable(obj))}
then the skeleton attribute is automatically set.
As long as \code{skeleton} has the right shape, it should be a precise
inverse
of \code{\link{unlist}}. These equalities hold:
\preformatted{
- relist(unlist(x), skeleton) == x
+ relist(unlist(x), x) == x
unlist(relist(y, skeleton)) == y
x <- as.relistable(x)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] dendrapply.Rd patch
One typo, and added rapply() to 'See also' list.
Dan
--
www.stats.ox.ac.uk/~davison
--- /usr/local/src/R/R-svn-trunk/src/library/stats/man/dendrapply.Rd
2008-08-16 13:41:48.0 +0100
+++ /home/dan/dendrapply-new.Rd 2008-08-16 19:10:51.0 +0100
@@ -9,7 +9,7 @@
\description{
Apply function \code{FUN} to each node of a \code{\link{dendrogram}}
recursively. When \code{y <- dendrapply(x, fn)}, then \code{y} is a
- dendrogram of the same graph structure as \code{x} and each for each node,
+ dendrogram of the same graph structure as \code{x} and for each node,
\code{y.node[j] <- FUN( x.node[j], ...)} (where \code{y.node[j]} is an
(invalid!) notation for the j-th node of y.
}
@@ -33,7 +33,8 @@
\note{this is still somewhat experimental, and suggestions for
enhancements (or nice examples of usage) are very welcome.}
\seealso{\code{\link{as.dendrogram}}, \code{\link{lapply}} for applying
- a function to each component of a \code{list}.
+ a function to each component of a \code{list}, \code{\link{rapply}}
+ for doing so to each non-list component of a nested list.
}
\examples{
require(graphics)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unlist on nested pairlists
unlist(recursive=FALSE) returns NULL elements when passed a nested pairlist containing non-NULL data: x <- pairlist(pairlist(1:2)) unlist(x, recursive=FALSE) ## [[1]] ## NULL version 2.7.2 RC (2008-08-18 r46382) under linux I'm unaware of any motivation for constructing the above data structure, but if unlist is going to operate on it without error I would be surprised if that is the correct answer. However as I do not know anything about pairlists I have not submitted this to r-bugs. I'd also appreciate any comments on the following issue: The documentation for unlist says recursive: logical. Should unlisting be applied to list components of 'x'? Now, y <- list(a=1:2, b=list(b1=3:4, b2=5:6)) My expectation was that unlist(y, recursive=FALSE) would be the following length 3 list: list(a1=1, a2=2, b=list(b1=3:4, b2=5:6)) However str(unlist(y, recursive=FALSE)) ## List of 4 ## $ a1 : int 1 ## $ a2 : int 2 ## $ b.b1: int [1:2] 3 4 ## $ b.b2: int [1:2] 5 6 I'm tempted to say that, contary to the documentation, (partial) unlisting has in fact been applied to a list component of x (x$b): it contributes 2 components to the result, rather than one. I say partial because the numeric vectors in x$b have not been broken up into separate elements in the answer. However, I imagine that this is the intended behaviour, and that my incorrect expectation is a result of not understanding the underlying list representations. Any explanation would be appreciated. Dan -- http://www.stats.ox.ac.uk/~davison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] repeat bug report: as.factor argument to row / col fails if NULL dimnames
This bug was reported to r-devel by Martin Morgan on 13th May 2008 (original email pasted below). However I couldn't locate it in the bug tracker (with searches for row, col, as\.factor) It is still present in today's svn version (rev 47115). I hope I'm doing something useful by bringing it up again. I have not sent this to r-bugs, as I'm concerned that not locating it in the bug tracker could be my failing. Dan original report: -- col(matrix(0, 5, 5), as.factor=TRUE) fails > col(matrix(0, 5, 5), as.factor=TRUE) Error in factor(.Internal(col(dim(x))), labels = colnames(x)) : invalid labels; length 0 should be 1 or 5 when the matrix has no dimnames. This is not as advertised. I would have expected the equivalent of factor(.Internal(col(dim(x))), labels=colnames(x, do.NULL=FALSE, prefix="")) > sessionInfo() R version 2.8.0 Under development (unstable) (2008-05-13 r45682) x86_64-unknown-linux-gnu Martin -- Martin Morgan Computational Biology / Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: Arnold Building M2 B169 Phone: (206) 667-2793 -- -- http://www.stats.ox.ac.uk/~davison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] stopifnot() suggestion
If an expression is passed to stopifnot() which contains missing values,
then the resulting error message is somewhat baffling until you are used
to it, e.g.
> x <- y <- rep(TRUE, 10)
> y[7] <- NA
> stopifnot(x, y)
Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
stop(paste(deparse(mc[[i + :
missing value where TRUE/FALSE needed
A minor change to stopifnot() produces the following behaviour:
> stopifnot(x, y)
Error in stopifnot(x, y) : y contains missing values
My attempt at a suitable modification follows, and below that the original
function definition. Is a change along these lines appropriate?
## Altered version
stopifnot <- function (...) {
n <- length(ll <- list(...))
if (n == 0)
return(invisible())
mc <- match.call()
for (i in 1:n) {
if(any(is.na(r <- eval(ll[[i]] stop(paste(deparse(mc[[i + 1]])), "
contains missing values")
if (!(is.logical(r) && all(r)))
stop(paste(deparse(mc[[i + 1]]), "is not TRUE"), call. = FALSE)
}
}
## from R-2.1.1/src/library/base/R/stop.R
stopifnot <- function(...)
{
n <- length(ll <- list(...))
if(n == 0)
return(invisible())
mc <- match.call()
for(i in 1:n)
if(!(is.logical(r <- eval(ll[[i]])) && all(r)))
stop(paste(deparse(mc[[i+1]]), "is not TRUE"), call. = FALSE)
}
Thanks,
Dan
> version
_
platform i386-pc-linux-gnu
arch i386
os linux-gnu
system i386, linux-gnu
status
major2
minor2.0
year 2005
month10
day 06
svn rev 35749
language R
--
Dan Davison
Committee on Evolutionary Biology
University of Chicago, U.S.A.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] stopifnot() suggestion
On Wed, 1 Mar 2006, Roger D. Peng wrote:
> Wouldn't it be better to do something like
>
> stopifnot(all(!is.na(x)), all(!is.na(y)), x, y)
>
> rather than have stopifnot() go checking for NAs? I agree the message is
> strange but if having non-NA values is really a condition, then why not just
> put it in the call to stopifnot()?
>
> -roger
>
I was thinking of a fallible R user accidentally testing the truth of an
expression with NAs, rather than of a situation where you remember that
there may be missing values. For example
> f <- function() { x <- NA ; if(x != 4) stop("x should be 4") }
> g <- function() { x <- NA ; stopifnot(x == 4) }
> f()
Error in if (x != 4) stop("x should be 4") :
missing value where TRUE/FALSE needed
> g()
Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
stop(paste(deparse(mc[[i + :
missing value where TRUE/FALSE needed
If you write the error-checking code represented by f(), you get a message
which is very helpful in correcting your error. But someone who uses
stopifnot() instead gets the output of g(). Even a user who knows the
origin of the code in the error message doesn't know which of several
stopifnot()s is responsible.
Dan
> Dan Davison wrote:
>> If an expression is passed to stopifnot() which contains missing values,
>> then the resulting error message is somewhat baffling until you are used to
>> it, e.g.
>>
>>> x <- y <- rep(TRUE, 10)
>>> y[7] <- NA
>>> stopifnot(x, y)
>> Error in if (!(is.logical(r <- eval(ll[[i]])) && all(r)))
>> stop(paste(deparse(mc[[i + :
>> missing value where TRUE/FALSE needed
>>
>> A minor change to stopifnot() produces the following behaviour:
>>
>>> stopifnot(x, y)
>> Error in stopifnot(x, y) : y contains missing values
>>
>> My attempt at a suitable modification follows, and below that the original
>> function definition. Is a change along these lines appropriate?
>>
>> ## Altered version
>>
>> stopifnot <- function (...) {
>> n <- length(ll <- list(...))
>> if (n == 0)
>> return(invisible())
>> mc <- match.call()
>> for (i in 1:n) {
>> if(any(is.na(r <- eval(ll[[i]] stop(paste(deparse(mc[[i +
>> 1]])), " contains missing values")
>> if (!(is.logical(r) && all(r)))
>> stop(paste(deparse(mc[[i + 1]]), "is not TRUE"), call. =
>> FALSE)
>> }
>> }
>>
>>
>> ## from R-2.1.1/src/library/base/R/stop.R
>>
>> stopifnot <- function(...)
>> {
>> n <- length(ll <- list(...))
>> if(n == 0)
>> return(invisible())
>> mc <- match.call()
>> for(i in 1:n)
>> if(!(is.logical(r <- eval(ll[[i]])) && all(r)))
>> stop(paste(deparse(mc[[i+1]]), "is not TRUE"), call. = FALSE)
>> }
>>
>>
>> Thanks,
>>
>> Dan
>>
>>
>>> version
>> _
>> platform i386-pc-linux-gnu
>> arch i386
>> os linux-gnu
>> system i386, linux-gnu
>> status
>> major2
>> minor2.0
>> year 2005
>> month10
>> day 06
>> svn rev 35749
>> language R
>>
>> --
>> Dan Davison
>> Committee on Evolutionary Biology
>> University of Chicago, U.S.A.
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Roger D. Peng | http://www.biostat.jhsph.edu/~rpeng/
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
