search for: diagonalmatrix

...in .nextMethod(x = x, i = i, j = j) : 'i' has no integer column number should never happen; please report In addition: Warning messages: 1: Ambiguous method selection for "%*%", target "ddiMatrix#dgCMatrix" (the first of the signatures shown will be used) diagonalMatrix#CsparseMatrix ddenseMatrix#CsparseMatrix in: .findInheritedMethods(classes, fdef, mtable) I got 4 other copies of the same warning. Will play around a bit more... This is really strange. Thanks -- Jose Quesada, PhD. http://www.andrew.cmu.edu/~jquesada

Hi, I have sparse (tridiagonal) matrices, and I use the Matrix package for handling them. For certain computations, I need to either set the first row to zero, or double the last row. I find that neither operation preserves sparsity, eg > m <- Diagonal(5) > m 5 x 5 diagonal matrix of class "ddiMatrix" [,1] [,2] [,3] [,4] [,5] [1,] 1 . . . . [2,] . 1

...rix is that half a dozen CRAN packages at least need to be slightly fixed before that Matrix version becomes default on CRAN, as these packages make assumptions about unspecified behavior of some Matrix functions, notably Matrix::Matrix() which in that next version of Matrix will produce "diagonalMatrix" instead of "CsparseMatrix" objects in more cases.... a good thing, but not what those packages have assumed... @Spencer: Are you actively using 'giveCsparse = ..' somewhere in your code? If not, why would you be interested in the details of the changes (which would...

...ozen CRAN packages at least need to be slightly fixed > before that Matrix version becomes default on CRAN, as these > packages make assumptions about unspecified behavior of some > Matrix functions, notably Matrix::Matrix() which in that next version > of Matrix will produce "diagonalMatrix" instead of > "CsparseMatrix" objects in more cases.... a good thing, but not > what those packages have assumed... > > @Spencer: Are you actively using 'giveCsparse = ..' somewhere > in your code? > If not, why would you be interested in the detail...

Hi: I have some problems when I use the function "solve" function in a loop. In the following code, I have a diagonal martix "ttt" whose elements change in every iteration in a loop. I defined a "dpoMatrix"class before the loop so I do not need to define this class every time in the loop. The reason is to save some computing time. The code is below. The inverse

Hi, Martin, Ben, et al.: On 2020-07-21 04:33, Martin Maechler wrote: >>>>>> Ben Bolker >>>>>> on Mon, 20 Jul 2020 20:11:04 -0400 writes: >> ? "form" -> "from". Diff against latest SVN: >> Index: sparse.model.matrix.Rd >> =================================================================== >> ---

...list(c("a", "b", "c"), c("A", "B", "C"))) | > 3 x 3 Matrix of class "dgeMatrix" | > A B C | > a 1 4 7 | > b 2 5 8 | > c 3 6 9 | > | > Matrix> (I3 <- Matrix(diag(3)))# identity, i.e., unit "diagonalMatrix" | > 3 x 3 diagonal matrix of class "ddiMatrix" | > [,1] [,2] [,3] | > [1,] 1 . . | > [2,] . 1 . | > [3,] . . 1 | > | > Matrix> str(I3) # note the empty 'x' slot | > Formal class 'ddiMatrix' [package &...

...;c"), c("A", "B", "C"))) > | > 3 x 3 Matrix of class "dgeMatrix" > | > A B C > | > a 1 4 7 > | > b 2 5 8 > | > c 3 6 9 > | > > | > Matrix> (I3 <- Matrix(diag(3)))# identity, i.e., unit "diagonalMatrix" > | > 3 x 3 diagonal matrix of class "ddiMatrix" > | > [,1] [,2] [,3] > | > [1,] 1 . . > | > [2,] . 1 . > | > [3,] . . 1 > | > > | > Matrix> str(I3) # note the empty 'x' slot > |...

Fine with me as long as eliminating the inconveniences associated with it can be put on the roadmap. The alias instability and the fact that the user has no way to know if s/he should do ?`foo,numeric-method` or ?`foo,numeric,ANY-method` to find the method has been a long-standing problem. H. On 3/21/19 21:29, Michael Lawrence wrote: If we started over, I'd try to avoid this sort of

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: