similar to: Problems with crossprod

Hi there, using cbind with a numeric and raw argument produces an incorrect result. I've posted some details below, kind regards, Mike. e.g. > cbind(0, as.raw(0)) [,1] [,2] [1,] 0 6.950136e-310 A longer example shows that the result is not a rounding error, is not consistent, and repeated applications get different results. > cbind(0, as.raw(1:10))

Thanks Brodie, that's some nice detective work. If someone wanted to grant me access to Bugzilla, I'll be happy to post the bug and patch there (with your permission Brodie?) and help this bug get fixed. Mike. On Tue., 25 Sep. 2018, 10:53 pm brodie gaslam, <brodie.gaslam at yahoo.com> wrote: > > > For what it's worth the following patch fixes that particular problem

Dear Mr. Tuszynski, I would like to request what I believe would be a beneficial update / patch to the runmean() function in the caTools package. Consider the following R>> x = 1:100 R>> is.integer(x) [1] TRUE R>> library(caTools) R>> head(runmean(x, 5, alg="exact")) [1] 8.487983e-314 1.060998e-313 1.273197e-313 1.697597e-313 2.121996e-313 2.546395e-313

I found out the other day that crossprod() will take a single matrix argument; crossprod(x) notionally returns crossprod(x,x). The two forms do not return identical matrices: x <- matrix(rnorm(3000000),ncol=3) M1 <- crossprod(x) M2 <- crossprod(x,x) R> max(abs(M1-M2)) [1] 1.932494e-08 But what really surprised me is that crossprod(x) is slower than crossprod(x,x): R>

Hi everyone, I do a lot of work with large variance matrices, and I like to use "crossprod" for speed and to keep everything symmetric, i.e. I often compute "crossprod(Q %*% t(A))" for "A %*% Sigma %*% t(A)", where "Sigma" decomposes as "t(Q) %*% Q". I notice in the code that "crossprod", current definition > crossprod function (x,

Hello, I have come across a troubling problem in which my call to crossprod will occasionally produce NaNs. That is, a proper matrix cross-product will be produced except that some of the matrix elements will arbitrarily be NaN. For my purposes, this is extremely bad. On several different R sessions run this morning this example below may fail a few times out of a million, though sometimes not at

Hi I've got two builds of R, one using g77 (version 3.4.6) and the other using gfortran (version 4.1.2). The two builds are otherwise identical as far as I can tell. The one which used g77 performs crossprod()s roughly twice as fast as the gfortran one. I'm wondering if this rings a bell with anyone, and if so, are you aware of any configure settings which will improve the performance

Hi I have a square matrix Ainv of size N-by-N where N ~ 1000 I have a rectangular matrix H of size N by n where n ~ 4. I have a vector d of length N. I need X = solve(t(H) %*% Ainv %*% H) %*% t(H) %*% Ainv %*% d and H %*% X. It is possible to rewrite X in the recommended crossprod way: X <- solve(quad.form(Ainv, H), crossprod(crossprod(Ainv, H), d)) where quad.form() is a little

# Your mailer is set to "none" (default on Windows), # hence we cannot send the bug report directly from R. # Please copy the bug report (after finishing it) to # your favorite email program and send it to # # r-bugs@r-project.org # ###################################################### # The last line of following code produces a segmentation fault: x <- 1:10 f <- gl(5,2)

hi, the help page for crossprod states that crossprod(A,B) is faster than t(A) %*% B; experimentation certainly bears this out. more alarming is the evidence that crossprod(t(A), B) is faster than A %*% B: on a PII laptop, 128MB memory, win98, R-1.5.0.-patched precompiled (no ATLAS): > A <- matrix(rnorm(250000),500,500) > B <- matrix(rnorm(250000),500,500) > for (i in 1:5) {

Dear Rdevelopers The background for this email is that I was helping a PhD student to improve the speed of her R code. I suggested to replace calls like t(AA)%*% BB by crossprod(AA,BB) since I expected this to be faster. The surprising result to me was that this change actually made her code slower. > ## Examples : > > AA <- matrix(rnorm(3000*1000),3000,1000) > BB <-

Hi Martin I got stung by this last week. glmnet produces a coefficient matrix of class ?dgCMatrix? If a predictor matrix was created using sparseMatrix as follows, one gets unexpected results, as this simple example shows. My fix was easy (I always convert the predictor matrix to class ?dgCMatrix? now) Trevor > y=Matrix(diag(4)) > y 4 x 4 diagonal matrix of class "ddiMatrix"

Hi Martin, package arules heavily relies on ngCMatrix and uses multiplication and addition for logical operations. I think it makes sense that in a mixed operation with one dgCMatrix and one ngCMatrix the ngCMatrix should be "promoted" to a dgCMatrix. The current behavior of %*% and friends is in deed confusing: > m <- matrix(sample(c(0,1), 5*5, replace=TRUE), nrow=5) >

The following is at least as much out of intellectual curiosity as for practical reasons. On reviewing some code written by novices to R, I came across: crossprod(x, y)[1,1] I thought, "That isn't a very S way of saying that, I wonder what the penalty is for using 'crossprod'." To my surprise the penalty was substantially negative. Handily the client had S-PLUS as

Hi the manpage says that crossprod(x,y) is formally equivalent to, but faster than, the call 't(x) %*% y'. I have a vector 'a' and a matrix 'A', and need to evaluate 't(a) %*% A %*% a' many many times, and performance is becoming crucial. With f1 <- function(a,X){ ignore <- t(a) %*% X %*% a } f2 <- function(a,X){ ignore <-

Hi All, I did a google search and could not find the answer. Thus I post this message. I found runmax only work for positive numbers. x = rep(-1,10) runmax(x,3) x = rep(0, 10) runmax(x,3) for 32-bit R, i got very small numbers: 2.121996e-314 for 64-bit R, i got NaN. Is it a bug in runmax? or should this be included in the documentation that runmax only for positive numbers? however,

For what it's worth the following patch fixes that particular problem on my system.? I have not checked very carefully to make sure this does not cause other problems, but at a high level it seems to make sense.? In this particular part of the code I believe `mode` is taken to be the highest type of "column" encountered by `ctype` and based on conditionals it can (I think) be up to

This is a Request For Comment, also BCCed to 390 package maintainers of reverse dependencies of the Matrix package. Most users and package authors working with our 'Matrix' package will be using it for numerical computations, and so will be using "dMatrix" (d : double precision) matrix objects M, and indirectly, e.g., for M >= c will also use "lMatrix" (l: