 pkg/TODO 2007/06/07 09:04:34 1887
+++ pkg/TODO 2008/01/15 10:16:29 2105
@@ 1,7 +1,5 @@
Check for DimNames propagation in coercion and other operations.

 rcond methods for sparseMatrix classes

 Report the problem in the Linux ldexp manual page. The second and
third calls in the Synopsis should be to ldexpf and ldexpl.
@@ 52,6 +50,19 @@
for all "dsparse*" > "lsparse*" and vice versa.
How can one do this {in a documented way} ?
+ Think of constructing setAs(...) calls automatically in order to
+ basically enable all ``sensible'' as(fromMatrix, toMatrix) calls,
+ possibly using canCoerce(.)
+
+ setAs(, "[dln]Matrix") for in {Matrix or denseMatrix + sparseMatrix}
+
+ When we have a packed matrix, it's a waste to go through "full" to "sparse":
+ ==> implement
+ setAs("dspMatrix", "sparseMatrix")
+ setAs("dppMatrix", "sparseMatrix")
+ setAs("dtpMatrix", "sparseMatrix")
+ and the same for "lsp" , "ltp" and "nsp" , "ntp" !
+
 tcrossprod(x, y) : do provide methods for y != NULL
calling Lapack's DGEMM for "dense"
[200512xx: done for dgeMatrix at least]
@@ 73,13 +84,6 @@
 is.na() method for all our matrices [ ==> which(*, arr.ind=TRUE) might work ]
 When we have a packed matrix, it's a waste to go through "full" to "sparse":
 ==> implement
 setAs("dspMatrix", "sparseMatrix")
 setAs("dppMatrix", "sparseMatrix")
 setAs("dtpMatrix", "sparseMatrix")
 and the same for "lsp" , "ltp" and "nsp" , "ntp" !

 use .Call(Csparse_drop, M, tol) in more places,
both with 'tol = 0.' to drop "values that happen to be 0" and for
zapsmall() methods for Csparse*
@@ 92,10 +96,6 @@
 chol() and determinant() should ``work'': proper result or "good" error
message.
 Think of constructing setAs(...) calls automatically in order to
 basically enable all ``sensible'' as(fromMatrix, toMatrix) calls,
 possibly using canCoerce(.)

 make sure *all* group methods have (maybe "bailout") setMethod for "Matrix".
e.g. zapsmall() fails "badly"
@@ 109,16 +109,6 @@
 rbind(, ) does not work (e.g. , )
 setAs(, "[dln]Matrix" ) for in {Matrix or denseMatrix + sparseMatrix}

 Tell users about the possibility to disable the "S4generic but somewhat slow"
 cbind/rbind, e.g. via

 setHook(packageEvent("Matrix", "onLoad"),
 function(...) methods:::bind_activation(FALSE))

 ensure that M[0], M[FALSE], M[1:2] works as for traditional Matrices

 make sure M[FALSE, FALSE] works for all Matrices
{e.g. fails for M < Diagonal(4)}
@@ 133,6 +123,8 @@
> R/diagMatrix.R ('FIXME')
but also R/Ops.R to ensure spsym. + spsym. > spsym. etc
+ Diagonal(n) %*% A  too slow!! > ~/R/MM/Pkgex/Matrix/diagTamasex.R
+
 For a square sparse matrix 'b' {typically dgCMatrix or dgTMatrix},
we'd want a function "Mat_plus_t_Mat" < function(b) {....}
which computes the symmetric sparse matrix b + t(b)
@@ 142,12 +134,59 @@
!M where M is "sparseMatrix", currently always gives dense. This only
makes sense when M is ``really sparse''.
 column names of sparse matrices are not printed;
 we now "mention" them (if they are nonempty).
 Option:
 build show( ) on a function, possibly
 print.sparseMatrix(), which gets an argument such as
 'col.names.show = FALSE' which is documented and can be set to TRUE
+ msy < as(matrix(c(2:1,1:2),2), "dsyMatrix"); str(msy)
+
+ shows that the Cholesky factorization is computed ``too quickly''.
+ Can be a big pain for largish matrices, when it is unneeded.
+
+ example(Cholesky, echo=FALSE) ; cm < chol(mtm); str(cm); str(mtm)
+
+ shows that chol() does not seems to make use of an already
+ present factorization and rather uses one with more '0' in x slot.
+
+ diag(m) < val currently automatically works via m[cbind(i,i)] < val
+ However,
+ we need methods for 'diag<' at least for diagonalMatrix,
+ triangularMatrix, and probably also "dense*general*Matrix" since the
+ above currently goes via "matrix" and back instead of using the 'x' slot
+ directly.
+
+ image(M, ..): Think about an optional smart option which keeps
+ "0 > transparent" and allows colors to differentiate negative and
+ positive entries.
+
+ examples for solve( Cholesky(.), b, system = c("A", "LDLt"....))
+ probably rather in man/CHMfactorclass.Rd than man/Cholesky.Rd
+
+ (A + tr(A))/2 := the symmetric part of A, is needed in several
+ circumstances; unfortunately it's not "smart" (preserving symmetry, ...)
+ > define a generic and methods for it!
+ Names: symPart(A) or symMat(A) or symmetrize(A) or ... ?
+ Googling around I found that Nick Higham has a GPL contributed Matlab
+ toolbox where he uses symmpart(A) := (A + A') /. 2
+ {and skewpart(A) := (A  A') /. 2}
+
+ tr(A %*% B) {and even tr(A %*% B %*% C) ...} are also needed
+ frequently in some computations {conditional normal distr. ...}.
+ Since this can be done faster than by
+ sum(diag(A %*% B)) even for traditional matrices, e.g.
+ sum(A * t(B)) or {even faster for "full" mat}
+ crossprod(as.vector(A), as.vector(B))
+ and even more so for, e.g. %*%
+ {used in Soeren's 'gR' computations},
+ we should also provide a generic and methods.
+
+ qr.R(qr(x)) may differ for the "same" matrix, depending on it being
+ sparse or dense:
+ "qr.R() may differ from qr.R() because of permutations"
+
+ This is not really acceptable and currently influences rcond() as well.
+
+ chol() and qr() generic: currently have *two* arguments, and give
+
+ New generic for "chol" does not agree with implicit generic from package "base"; a new generic will be assigned with package "Matrix"
+
+ New generic for "qr" does not agree with implicit generic from package "base"; a new generic will be assigned with package "Matrix"
 'arules' needs fast colSums() and rowSums()  for ngCMatrix;
 do it for "nMatrix" and "lMatrix" and return *integer*
+ It was mentioned by an Rcore member that he thought it did not make
+ sense to also dispatch on 'tol' or 'pivot' ... > maybe change that..