# Unexpected errors in sparse Matrix arithmetic with zero-length dimensions Classic List Threaded 2 messages Reply | Threaded
Open this post in threaded view
|

## Unexpected errors in sparse Matrix arithmetic with zero-length dimensions

 Dear list, The Matrix package exhibits some unexpected behaviour in its arithmetic methods for the edge case of a sparse matrix with a dimension of zero length. The example below is the most illustrative, where changing the contents of the vector causes the subtraction to fail for a sparse matrix with no columns:       > library(Matrix) > x <- rsparsematrix(10, 0, density=0.1) >  > x - rep(1, nrow(x)) # OK  > x - rep(0, nrow(x)) # fails Error in .Ops.recycle.ind(e1, len = l2) :    vector too long in Matrix - vector operation This is presumably because Matrix recognizes that subtraction of zero preserves sparsity and thus uses a different method in the second case. However, I would have expected subtraction of a zero vector to work if subtraction of a general vector is permissible. This is accompanied by a host of related errors for sparsity-preserving arithmetic: > x / 1 # OK > x / rep(1, nrow(x)) # fails  Error in .Ops.recycle.ind(e1, len = l2) :    vector too long in Matrix - vector operation >  > x * 1 # OK > x * rep(1, nrow(x)) # fails Error in .Ops.recycle.ind(e1, len = l2) :    vector too long in Matrix - vector operation        A different error is raised for a sparse matrix with no rows: > y <- rsparsematrix(0, 10, density=0.1) >  > y - numeric(1) # OK > y - numeric(0) # fails Error in y - numeric(0) : - numeric(0) is undefined I would have expected to just get 'y' back, given that the same code works fine for other Matrix classes: > z <- as(y, "dgeMatrix") > z - numeric(0) # OK Correct behaviour of zero-dimension sparse matrices is practically important to me; I develop a number of packages that rely on Matrix classes, and in those packages, I do a lot of unit testing with zero- dimension inputs. This ensures that my functions return sensible results or fail gracefully in edge cases that might be encountered by users. The current behaviour of sparse Matrix arithmetic causes my unit tests to fail for no (obvious) good reason. Best, Aaron Lun Research Associate CRUK Cambridge Institute University of Cambridge > sessionInfo() R Under development (unstable) (2019-01-14 r75992) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Ubuntu 16.04.5 LTS Matrix products: default BLAS: /home/cri.camres.org/lun01/Software/R/trunk/lib/libRblas.so LAPACK: /home/cri.camres.org/lun01/Software/R/trunk/lib/libRlapack.so 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:  stats     graphics  grDevices utils     datasets  methods   base      other attached packages:  Matrix_1.2-15 loaded via a namespace (and not attached):  compiler_3.6.0  grid_3.6.0      lattice_0.20-38 ______________________________________________ [hidden email] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.
Reply | Threaded
Open this post in threaded view
|

## Re: Unexpected errors in sparse Matrix arithmetic with zero-length dimensions

 >>>>> Aaron Lun >>>>>     on Sun, 10 Feb 2019 15:22:17 +0000 writes:     > Dear list,     > The Matrix package exhibits some unexpected behaviour in its arithmetic     > methods for the edge case of a sparse matrix with a dimension of zero     > length. The example below is the most illustrative, where changing the     > contents of the vector causes the subtraction to fail for a sparse     > matrix with no columns:      >          >> library(Matrix)     >> x <- rsparsematrix(10, 0, density=0.1)     >>       >> x - rep(1, nrow(x)) # OK      >> x - rep(0, nrow(x)) # fails     > Error in .Ops.recycle.ind(e1, len = l2) :      >   vector too long in Matrix - vector operation This is indeed clearly a lapsus of us / mine  as well as the next examples:  Will all be fixed  "around" .Ops.recycle.ind()     > This is presumably because Matrix recognizes that subtraction of zero     > preserves sparsity and thus uses a different method in the second case.     > However, I would have expected subtraction of a zero vector to work if     > subtraction of a general vector is permissible. This is accompanied by     > a host of related errors for sparsity-preserving arithmetic:     >> x / 1 # OK     >> x / rep(1, nrow(x)) # fails      > Error in .Ops.recycle.ind(e1, len = l2) :      >   vector too long in Matrix - vector operation     >>       >> x * 1 # OK     >> x * rep(1, nrow(x)) # fails     > Error in .Ops.recycle.ind(e1, len = l2) :      >   vector too long in Matrix - vector operation     >            > A different error is raised for a sparse matrix with no rows:     >> y <- rsparsematrix(0, 10, density=0.1)     >>       >> y - numeric(1) # OK     >> y - numeric(0) # fails     > Error in y - numeric(0) : - numeric(0) is undefined Thank you, that's another lapsus, I will fix before the next release of Matrix.     > I would have expected to just get 'y' back, given that the same code     > works fine for other Matrix classes:     >> z <- as(y, "dgeMatrix")     >> z - numeric(0) # OK sure.     > Correct behaviour of zero-dimension sparse matrices is practically     > important to me; I develop a number of packages that rely on Matrix     > classes, and in those packages, I do a lot of unit testing with zero-     > dimension inputs. This ensures that my functions return sensible     > results or fail gracefully in edge cases that might be encountered by     > users. The current behaviour of sparse Matrix arithmetic causes my unit     > tests to fail for no (obvious) good reason. Interesting that you need 0-dim sparse matrices.  I agree they should work, too... and will fix (but it seems they haven't been used much by others;  else I would have expected these cases to have been reported long ago). Further note that in R,   maintainer("Matrix") gives a nice address to send such findings. (similarly for all other R packages !) Thank you very much once more! Martin     > Best,     > Aaron Lun     > Research Associate     > CRUK Cambridge Institute     > University of Cambridge -- Martin   Seminar für Statistik, ETH Zürich   HG G 16         Rämistrasse 101 CH-8092 Zurich, SWITZERLAND ______________________________________________ [hidden email] mailing list -- To UNSUBSCRIBE and more, see https://stat.ethz.ch/mailman/listinfo/r-helpPLEASE do read the posting guide http://www.R-project.org/posting-guide.htmland provide commented, minimal, self-contained, reproducible code.