A new version of pqR is now available at pqR-project.org, which fixes
several bugs that are also present in the latest R Core patch release
(r66002). A number of bugs found previously during pqR development
are also unfixed in the latest R Core release. Here is the list of
these bugs that are unfixed in r66002 (including documentation
deficiencies), taken from the pqR bug fix and documentation update
sections of the pqR NEWS file (pqR-project.org/NEWS.txt):
o The documentation for c now says how the names for the result are
determined, including previously missing information on the
use.names argument, and on the role of the names of arguments in
the call of c. This documentation is missing in R-2.15.0 and
R-3.1.0.
o The documentaton for diag now documents that a diagonal matrix is
always created with type double or complex, and that the names of
an extracted diagonal vector are taken from a names attribute (if
present), if not from the row and column names. This information
is absent in the documentation in R-2.15.1 and R-3.1.0.
o Incorrect information regarding the pointer protection stack was
removed from help(Memory). This incorrect information is present
in R-2.15.0 and R-3.1.0 as well.
o There is now information in help(Arithmetic) regarding what
happens when the operands of an arithmetic operation are NA or
NaN, including the arbitrary nature of the result when one
operand is NA and the other is NaN. There is no discussion of
this issue in the documentation for R-2.15.0 and R-3.1.0.
o Fixed lack of protection bugs in the equal and greater functions
in sort.c. These bugs are also present in R-2.15.0 and R-3.1.0.
o Fixed lack of protection bugs in the D function in deriv.c.
These bugs are also present in R-2.15.0 and R-3.1.0.
o Fixed argument error-checking bugs in getGraphicsEventEnv and
setGraphicsEventEnv (also present in R-2.15.0 and R-3.1.0).
o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
x <- t(5)
print (x %*% c(3,4))
print (crossprod(5,c(3,4)))
The call of crossprod produced an error, whereas the
corresponding use of %*% does not.
In pqR-2013-12-29, this bug also affected the expression t(5) %*%
c(3,4), since it is converted to the equivalent of
crossprod(5,c(3,4)).
o Fixed a problem in R_AllocStringBuffer that could result in a
crash due to an invalid memory access. (This bug is also present
in R-2.15.0 and R-3.0.2.)
o The documentation for aperm now says that the default method does
not copy attributes (other than dimensions and dimnames).
Previously, it incorrecty said it did (as is the case also in
R-2.15.0 and R-3.0.2).
o Fixed the following bug (also present in R-2.15.0 and R-3.0.2):
v <- c(1,2)
m <- matrix(c(3,4),1,2)
print(t(m)%*%v)
print(crossprod(m,v))
in which crossprod gave an error rather than produce the answer
for the corresponding use of %*%.
o Raising -Inf to a large value (eg, (-Inf)^(1e16)) no longer
produces an incomprehensible warning. As before, the value
returned is Inf, because (due to their limited-precision
floating-point representation) all such large numbers are even
integers.
o Fixed a bug (also present in R-2.15.0 and R-3.0.1) illustrated by
the following code:
> a <- list(x=c(1,2),y=c(3,4))
> b <- as.pairlist(a)
> b$x[1] <- 9
> print(a)
$x
[1] 9 2
$y
[1] 3 4
The value printed for a has a$x[1] changed to 9, when it should
still be 1. See pqR issue #14.
o Fixed several bugs (also present in R-2.15.0 and R-3.0.1)
illustrated by the code below (see pqR issue #16):
v <- c(10,20,30)
v[[2]] <- NULL # wrong error message
x <- pairlist(list(1,2))
x[[c(1,2)]] <- NULL # wrongly gives an error, referring to misuse
# of the internal SET_VECTOR_ELT procedure
v<-list(1)
v[[quote(abc)]] <- 2 # internal error, this time for SET_STRING_ELT
a <- pairlist(10,20,30,40,50,60)
dim(a) <- c(2,3)
dimnames(a) <-
list(c("a","b"),c("x","y","z"))
print(a) # doesn't print names
a[["a","x"]] <- 0 # crashes with a
segmentation fault
o Fixed a bug where, for example, log(base=4) returned the natural
log of 4, rather than signalling an error.
o The documentation on what MARGIN arguments are allowed for apply
has been clarified, and checks for validity added. The call
> apply(array(1:24,c(2,3,4)),-3,sum)
now produces correct results (the same as when MARGIN is 1:2).
o Fixed a bug in which Im(matrix(complex(0),3,4)) returned a matrix
of zero elements rather than a matrix of NA elements.
o Now check for bad arguments for .rowSums, .colSums, .rowMeans,
and .rowMeans (would previously segfault if n*p too big).
o Fixed a bug where excess warning messages may be produced on
conversion to RAW. For instance:
> as.raw(1e40)
[1] 00
Warning messages:
1: NAs introduced by coercion
2: out-of-range values treated as 0 in coercion to raw
Now, only the second warning message is produced.
o A bug has been fixed in which rbind would not handle non-vector
objects such as function closures, whereas cbind did handle them,
and both were documented to do so.
Regards,
Radford Neal
It's hardly fair to call these "unfixed bugs". Most of them are better described as "unreported bugs", or, after this posting, "bugs reported with insufficient detail". We can't fix them if we don't know what they are, and it's not easy to determine that for most of the items below. Duncan Murdoch On 23/06/2014, 5:24 PM, Radford Neal wrote:> A new version of pqR is now available at pqR-project.org, which fixes > several bugs that are also present in the latest R Core patch release > (r66002). A number of bugs found previously during pqR development > are also unfixed in the latest R Core release. Here is the list of > these bugs that are unfixed in r66002 (including documentation > deficiencies), taken from the pqR bug fix and documentation update > sections of the pqR NEWS file (pqR-project.org/NEWS.txt): > > o The documentation for c now says how the names for the result are > determined, including previously missing information on the > use.names argument, and on the role of the names of arguments in > the call of c. This documentation is missing in R-2.15.0 and > R-3.1.0. > > o The documentaton for diag now documents that a diagonal matrix is > always created with type double or complex, and that the names of > an extracted diagonal vector are taken from a names attribute (if > present), if not from the row and column names. This information > is absent in the documentation in R-2.15.1 and R-3.1.0. > > o Incorrect information regarding the pointer protection stack was > removed from help(Memory). This incorrect information is present > in R-2.15.0 and R-3.1.0 as well. > > o There is now information in help(Arithmetic) regarding what > happens when the operands of an arithmetic operation are NA or > NaN, including the arbitrary nature of the result when one > operand is NA and the other is NaN. There is no discussion of > this issue in the documentation for R-2.15.0 and R-3.1.0. > > o Fixed lack of protection bugs in the equal and greater functions > in sort.c. These bugs are also present in R-2.15.0 and R-3.1.0. > > o Fixed lack of protection bugs in the D function in deriv.c. > These bugs are also present in R-2.15.0 and R-3.1.0. > > o Fixed argument error-checking bugs in getGraphicsEventEnv and > setGraphicsEventEnv (also present in R-2.15.0 and R-3.1.0). > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > x <- t(5) > print (x %*% c(3,4)) > print (crossprod(5,c(3,4))) > > The call of crossprod produced an error, whereas the > corresponding use of %*% does not. > > In pqR-2013-12-29, this bug also affected the expression t(5) %*% > c(3,4), since it is converted to the equivalent of > crossprod(5,c(3,4)). > > o Fixed a problem in R_AllocStringBuffer that could result in a > crash due to an invalid memory access. (This bug is also present > in R-2.15.0 and R-3.0.2.) > > o The documentation for aperm now says that the default method does > not copy attributes (other than dimensions and dimnames). > Previously, it incorrecty said it did (as is the case also in > R-2.15.0 and R-3.0.2). > > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > > v <- c(1,2) > m <- matrix(c(3,4),1,2) > print(t(m)%*%v) > print(crossprod(m,v)) > > in which crossprod gave an error rather than produce the answer > for the corresponding use of %*%. > > o Raising -Inf to a large value (eg, (-Inf)^(1e16)) no longer > produces an incomprehensible warning. As before, the value > returned is Inf, because (due to their limited-precision > floating-point representation) all such large numbers are even > integers. > > o Fixed a bug (also present in R-2.15.0 and R-3.0.1) illustrated by > the following code: > > > a <- list(x=c(1,2),y=c(3,4)) > > b <- as.pairlist(a) > > b$x[1] <- 9 > > print(a) > $x > [1] 9 2 > > $y > [1] 3 4 > > The value printed for a has a$x[1] changed to 9, when it should > still be 1. See pqR issue #14. > > o Fixed several bugs (also present in R-2.15.0 and R-3.0.1) > illustrated by the code below (see pqR issue #16): > > v <- c(10,20,30) > v[[2]] <- NULL # wrong error message > > x <- pairlist(list(1,2)) > x[[c(1,2)]] <- NULL # wrongly gives an error, referring to misuse > # of the internal SET_VECTOR_ELT procedure > > v<-list(1) > v[[quote(abc)]] <- 2 # internal error, this time for SET_STRING_ELT > > a <- pairlist(10,20,30,40,50,60) > dim(a) <- c(2,3) > dimnames(a) <- list(c("a","b"),c("x","y","z")) > print(a) # doesn't print names > > a[["a","x"]] <- 0 # crashes with a segmentation fault > > o Fixed a bug where, for example, log(base=4) returned the natural > log of 4, rather than signalling an error. > > o The documentation on what MARGIN arguments are allowed for apply > has been clarified, and checks for validity added. The call > > > apply(array(1:24,c(2,3,4)),-3,sum) > > now produces correct results (the same as when MARGIN is 1:2). > > o Fixed a bug in which Im(matrix(complex(0),3,4)) returned a matrix > of zero elements rather than a matrix of NA elements. > > o Now check for bad arguments for .rowSums, .colSums, .rowMeans, > and .rowMeans (would previously segfault if n*p too big). > > o Fixed a bug where excess warning messages may be produced on > conversion to RAW. For instance: > > > as.raw(1e40) > [1] 00 > Warning messages: > 1: NAs introduced by coercion > 2: out-of-range values treated as 0 in coercion to raw > > Now, only the second warning message is produced. > > o A bug has been fixed in which rbind would not handle non-vector > objects such as function closures, whereas cbind did handle them, > and both were documented to do so. > > Regards, > > Radford Neal > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
>>>>> Radford Neal <radford at cs.toronto.edu> >>>>> on Mon, 23 Jun 2014 11:24:35 -0400 writes:> A new version of pqR is now available at pqR-project.org, which fixes > several bugs that are also present in the latest R Core patch release > (r66002). A number of bugs found previously during pqR development > are also unfixed in the latest R Core release. Here is the list of > these bugs that are unfixed in r66002 (including documentation > deficiencies), taken from the pqR bug fix and documentation update > sections of the pqR NEWS file (pqR-project.org/NEWS.txt): Duncan Murdoch has already mentioned that "unfixed bugs" is a strong wording... I'm commenting on one subtopic only: [.........] > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > x <- t(5) > print (x %*% c(3,4)) > print (crossprod(5,c(3,4))) > The call of crossprod produced an error, whereas the > corresponding use of %*% does not. > In pqR-2013-12-29, this bug also affected the expression t(5) %*% > c(3,4), since it is converted to the equivalent of > crossprod(5,c(3,4)). (I'm not getting this last para... but that may be unimportant) [........] > o Fixed the following bug (also present in R-2.15.0 and R-3.0.2): > v <- c(1,2) > m <- matrix(c(3,4),1,2) > print(t(m)%*%v) > print(crossprod(m,v)) > in which crossprod gave an error rather than produce the answer > for the corresponding use of %*%. Both cases above concern %*%, crossprod() {and also tcrossprod()}, and always when one at least one operand is a vector... As S and R's terminology has always been mathematically correct and "knows" that a vector is not a 1-row matrix or 1-column matrix (which some people call row-vector and column-vector), R has indeed much more freedom to be lenient in how to promote vectors to matrices, and it has always done so tolerantly for some cases of "%*%", but even there is room for discussion, see below. Since about January, I have a corresponding entry in the TODO file of the Matrix package (which I maintain), and I (at least partly) agree with you, that we should *consider* changing the current behavior. The following is from my corresponding R script : ### NOTA BENE: vector %*% Matrix _and_ Matrix %*% vector : ### --------- ----------------- ----------------- ## The k-vector is treated as (1,k)-matrix *or* (k,1)-matrix ## on both sides whenever it "helps fit" the matrix dimensions: and one kind of reasoning would go to say that crossprod() and tcrossprod() should do the same. This would even make more cases work than (I think) your proposal. However, one can argue that the current behavior is quite consistent {there is more than one kind of consistency here; in this case it's the consistency of underlying C code IIRC}, and not strictly a bug. It is something which I am grateful you bring up for discussion, and I'm happy to settle here. Note that the Matrix package and many other packages that implement matrix multiplication methods, should then also follow the new semantic, and so this is typically rather for R-devel than R-patched. Note that from your first case example, one could also argue -- at least from my 'NOTA BENE' rule above -- that 5 %*% 3:4 should work, since 5 %*% rbind(3:4) does work, but 5 %*% cbind(3:4) does not. So you see, there are quite a few cases one could discuss, and have reasons pro and contra some of the changes. I will be too busy till the end of 'useR! 2014' and would want quite a bit of further thoughts before making a quick decision, notably about the cases I have in the appended products.Rout Martin Maechler, (ETH Zurich and R Core team) --------------- -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: products.Rout URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20140624/25ab3c6d/attachment.pl>