Giter VIP home page Giter VIP logo

matrixgenerics's Introduction

MatrixGenerics is an R/Bioconductor package that provides the S4 generics for popular row and column aggregation functions for matrices (e.g. colVars(), rowMedians()). It follows the API developed by the matrixStats package. The target audience for MatrixGenerics are R package developers that want to write code that can automatically handle different kind of matrix implementations: for example base R matrix, the S4 Matrix (including sparse representations), and DelayedMatrix objects.

A prerequisite to handle these matrix objects is that a package with the corresponding implementation is available. So far, there are six packages:

This package imports matrixStats and automatically forwards all function calls on matrix, array, or numeric objects to matrixStats. To handle other matrix-like objects, the user must manually install the package that implements row and column aggregation methods for those objects (e.g. the sparseMatrixStats, SparseArray, DelayedArray, or DelayedMatrixStats package).

See https://bioconductor.org/packages/MatrixGenerics for more information including how to install the release version of the package (please refrain from installing directly from GitHub).

matrixgenerics's People

Contributors

const-ae avatar hpages avatar jwokaty avatar nturaga avatar petehaitch avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Forkers

const-ae

matrixgenerics's Issues

Extend rowWeightedVars() to handle a matrix of weights

rowWeightedVars(X,w) currently handles a matrix X, the weights w must be a vector. Is it possible to extend this function handle a weights matrix W the same dimension as X?

I have an application in single cell genomics where X and W are both DelayedArray objects.

I posed a similar question under matrixStats, but I think your package is the right place for it

Best,
Gabriel

Why ... for every default function?

If see it correctly, in 81aa9cd you added ... back to every function, right?

If matrixStats explicitly states in the documentation that the ... are not used within a function, I am not sure what is the advantage of having it in the method signature?

Build Report Warning: File link 'rowRanges' in package 'SummarizedExperiment' does not exist

I just checked the build report and noticed that there is a WARNING on windows concerning the documentation of rowRanges

Found the following significant warnings:
  Rd warning: C:/Users/biocbuild/bbs-3.12-bioc/tmpdir/RtmpolctSY/R.INSTALLea848f42b6d/MatrixGenerics/man/rowRanges.Rd:62: file link 'RangedSummarizedExperiment' in package 'SummarizedExperiment' does not exist and so has been treated as a topic
  Rd warning: C:/Users/biocbuild/bbs-3.12-bioc/tmpdir/RtmpolctSY/R.INSTALLea848f42b6d/MatrixGenerics/man/rowRanges.Rd:63: file link 'rowRanges' in package 'SummarizedExperiment' does not exist and so has been treated as a topic

As the deadline is tomorrow, does anyone have capacity to fix the issue today? I assume the problem was introduced here by @hpages's commit to make rowRanges compatible with SummarizedExperiment (8b10d19#diff-d387fdcf206554302df9d454f50dd59442df365e2899b5afb221307fb21a6e10R25).

Generics for a sparseMatrixStats package?

Hi,

I have recently started to implement the matrixStats API for column sparse matrices (dgCMatrix) from the Matrix package. I saw the discussion on the BioC mailing list where to put the S4 generics for those functions and wondered what the current status of the discussion was?

(I am not quite sure if this is the right venue for this question, or if should rather post to the Bioc Mailing list, but I would appreciate any input :) )

Best Regards,
Constantin

CRAN instead of Bioconductor?

Have you guys considered releasing this package and matrixStats derivatives (DelayedMatrixStats(*) and sparseMatrixStats) on CRAN rather than Bioconductor? AFAIU, there's nothing specific to Bioconductor in them.

Having them on CRAN would reach a much bigger audience, give them much exposure, increase their usage by users and packages, and improve quality in the long run. This would benefit users and developers outside of the Bioconductor sphere. I find it's unfortunate to "hide them away" on Bioconductor. (I think there are other packages on Bioconductor that the same argument apply to)

cc/ @PeteHaitch @const-ae

Where should these generics live?

matrixStats 'owns' much of the API we (DelayedMatrixStats, matter, etc.) are trying to follow/mimic. The remainder is defined in base (e.g, colSums()); there may be other generics we wish to add (e.g., prcomp()). However, for performance reasons matrixStats uses ordinary functions rather than S4 (or S3). We want generic versions of these functions so that we can write methods that operate on matrix-like data structure; within Bioconductor, this generally means S4 generics but it may be worth also supporting S3 generics.

Based on the discussion in https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012273.html, I think our options are:

  1. Putting the generics in a Bioconductor package:
    a. A stand-alone MatrixGenerics package
    b. Sticking them in BiocGenerics
  2. Putting the generics in a CRAN package:
    a. A stand-alone MatrixGenerics package
    c. Sticking them in the matrixStats package
  3. Putting the generics in a required/recommended package:
    a. Sticking them in the Matrix package
    b. Sticking them in the stats4 package
    c. Sticking them in the the methods package
  • 1a, 1b, and 2a are lightweight since they contain no methods and have minimal dependencies. This also gives us (Bioconductor) the most explicit control.
  • 1a and 2a are similar, but 2a arguably makes it easier for non-BioC packages to incorporate. These require developers to know about yet another package.
  • 2b and 3a introduce dependencies (with compiled code), although Matrix "is 'Recommended' and comes with every R installation". Again, it's worth noting that matrixStats 'owns' much of the API but won't make use of the generics; right now, Matrix will use even less of the API (but of course it could add methods to support Matrix (sub)classes).
  • 3a-c are dependencies included in all R installations

Patch 1.12.1 not 100% backward compatible

I just tried to make the released version of sparseMatrixStats compatible with the patched version of MatrixGenerics (v.1.12.1). I noticed that in some corner cases the behavior did change compared with the previous version 1.12.0

For example, colMeans with a center argument used to return a named output:

mat <- matrix(1:12, nrow = 4, ncol = 3)
colnames(mat) <- c("A", "B", "C")

center <- matrixStats::colMeans2(mat)
MatrixGenerics::colVars(mat, center = center, useNames = NA)
#>        A        B        C
#> 1.666667 1.666667 1.666667

packageVersion("MatrixGenerics")
#> [1] '1.12.0'
packageVersion("matrixStats")
#> [1] '0.62.0'

Created on 2023-06-09 with reprex v2.0.2

But now it doesn't have names anymore:

mat <- matrix(1:12, nrow = 4, ncol = 3)
colnames(mat) <- c("A", "B", "C")

center <- matrixStats::colMeans2(mat)
MatrixGenerics::colVars(mat, center = center, useNames = NA)
#> [1] 1.666667 1.666667 1.666667

packageVersion("MatrixGenerics")
#> [1] '1.12.1'
packageVersion("matrixStats")
#> [1] '1.0.0'

Created on 2023-06-09 with reprex v2.0.2


The same problem occurs for colWeightedMedians

Update documentation of useNames in BioC 3.18?

For BioC 3.18, should we change the documentation of useNames from

#' @param useNames If \code{\link{NA}}, the default behavior of the function about naming support is remained. If \code{\link{FALSE}}, no naming support is done. Else if \code{\link{TRUE}}, names attributes of result are set.

to mimic/copy that of matrixStats:

If FALSE (default), no naming support is done. Else if `TRUE`, names attributes of result are set.)

Or do we need another release cycle where useNames = NA is supported?

matrixStats: Next release will break MatrixGenerics 1.2.0 package tests

Hi, I'm submitting the next release of matrixStats to CRAN. Reverse-package dependency checks show that out of 313 packages, MatrixGenerics package is the only package where its package tests fail (see below). These package tests are related to the tidying up and robustification of the center argument.

Since MatrixGenerics 1.2.0 is part of Bioconductor release, it needs to be "bug fixed" there. The version to test against is:

remotes::install_github("HenrikBengtsson/matrixStats", ref = "develop")

How quickly would you be able to roll out a fix there? The sooner the better for me as it spares me having to rerun all the revdep checks.

From https://github.com/HenrikBengtsson/matrixStats/blob/develop/revdep/problems.md#matrixgenerics:

...
   4.     └─matrixStats::rowSds(...)
   5.       └─matrixStats::rowVars(...)
  ── Error (test-api_compatibility.R:1445:2): rowVars works  ─────────────────────
  Error: Argument 'center' should be of the same length as number of rows of 'x': 16 != 12
  Backtrace:1. ├─MatrixGenerics::rowVars(...) test-api_compatibility.R:1445:8
   2. └─MatrixGenerics::rowVars(...)
   3.   └─MatrixGenerics:::.local(x, rows, cols, na.rm, center, ...)
   4.     └─matrixStats::rowVars(...)
  ── Error (test-api_compatibility.R:1466:2): rowWeightedMads works  ─────────────
  Error: Argument 'center' should be of the same length as number of rows of 'x': 1 != 6
  Backtrace:1. ├─MatrixGenerics::rowWeightedMads(...) test-api_compatibility.R:1466:8
   2. └─MatrixGenerics::rowWeightedMads(...)
   3.   └─matrixStats::rowWeightedMads(...)
  
  [ FAIL 10 | WARN 0 | SKIP 0 | PASS 300 ]
  Error: Test failures
  Execution halted

Warnings on Tokay2 about Missing Links in the Documentation

Hey Pete,

I just noticed that CHECK for sparseMatrixStats has many warnings which derive from MatrixGenerics http://bioconductor.org/checkResults/devel/bioc-LATEST/MatrixGenerics/tokay2-checksrc.html

There was recently some discussion on the Bioc-devel mailing list on a similar issue https://stat.ethz.ch/pipermail/bioc-devel/2020-April/016552.html

I just wanted to check if you are already looking into this? Otherwise I could try to draft a fix, but I cannot promising anything, because I have two deadlines until the end of the week 😅

Error in MatrixGenerics while running Pando

I ran the Joint RNA and ATAC multiomic tutorial till the Peak Calling and added MACS2 peak set to the Seurat Object (d149 in this case) and started running Pando from thereon. But later I get error in MatrixGenerics:::. I am not sure what I did wrong. Please help. I have ran this on 3 different systems and still getting the same error! Is there a sequence/order to which packages are installed in R?

library(Pando)
data(motifs)
d149.pando <-Seurat::FindVariableFeatures(d149, assay='RNA')
Calculating gene variances
0%   10   20   30   40   50   60   70   80   90   100%
[----|----|----|----|----|----|----|----|----|----|
**************************************************|
Calculating feature variances of standardized and clipped values
0%   10   20   30   40   50   60   70   80   90   100%
[----|----|----|----|----|----|----|----|----|----|
**************************************************|
> d149.pando <- initiate_grn(d149.pando)
> d149.pando <- find_motifs(
    d149.pando,
    pfm = motifs,
    genome = BSgenome.Hsapiens.UCSC.hg38
)
Adding TF info
Building motif matrix
Finding motif positions
Creating Motif object
> d149.pando <- infer_grn(d149.pando)
Selecting candidate regulatory regions near genes
Error in MatrixGenerics:::.load_next_suggested_package_to_search(x) : 
  Failed to find a rowMaxs() method for lgCMatrix objects.


sessionInfo()
R version 4.2.0 (2022-04-22)
Platform: x86_64-conda-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS/LAPACK: /ncbs_gs/nlsas_data/usershares/praghu/yojetsharma/.conda/envs/Signac/lib/libopenblasp-r0.3.21.so

locale:
 [1] LC_CTYPE=C                 LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats4    stats     graphics  grDevices utils     datasets  methods  
[8] base     

other attached packages:
 [1] DelayedMatrixStats_1.19.0         DelayedArray_0.23.2              
 [3] Matrix_1.5-1                      MatrixGenerics_1.9.1             
 [5] matrixStats_0.62.0                Pando_0.5.1                      
 [7] BSgenome.Hsapiens.UCSC.hg38_1.4.4 BSgenome_1.65.2                  
 [9] rtracklayer_1.57.0                Biostrings_2.65.6                
[11] XVector_0.37.1                    EnsDb.Hsapiens.v86_2.99.0        
[13] ensembldb_2.21.5                  AnnotationFilter_1.21.0          
[15] GenomicFeatures_1.49.7            AnnotationDbi_1.59.1             
[17] Biobase_2.57.1                    GenomicRanges_1.49.1             
[19] GenomeInfoDb_1.33.7               IRanges_2.31.2                   
[21] S4Vectors_0.35.4                  BiocGenerics_0.43.4              
[23] sp_1.5-0                          SeuratObject_4.1.2               
[25] Seurat_4.2.0                      Signac_1.8.0                     

loaded via a namespace (and not attached):
  [1] rappdirs_0.3.3              scattermore_0.8            
  [3] R.methodsS3_1.8.2           tidyr_1.2.1                
  [5] ggplot2_3.3.6               bit64_4.0.5                
  [7] knitr_1.40                  R.utils_2.12.0             
  [9] irlba_2.3.5                 data.table_1.14.2          
 [11] rpart_4.1.16                KEGGREST_1.37.3            
 [13] TFBSTools_1.35.0            RCurl_1.98-1.8             
 [15] generics_0.1.3              cowplot_1.1.1              
 [17] RSQLite_2.2.17              RANN_2.6.1                 
 [19] future_1.28.0               ggpointdensity_0.1.0       
 [21] bit_4.0.4                   tzdb_0.3.0                 
 [23] spatstat.data_2.2-0         xml2_1.3.3                 
 [25] httpuv_1.6.6                SummarizedExperiment_1.27.3
 [27] assertthat_0.2.1            DirichletMultinomial_1.39.0
 [29] viridis_0.6.2               xfun_0.33                  
 [31] hms_1.1.2                   promises_1.2.0.1           
 [33] fansi_1.0.3                 restfulr_0.0.15            
 [35] progress_1.2.2              caTools_1.18.2             
 [37] dbplyr_2.2.1                igraph_1.3.5               
 [39] DBI_1.1.3                   htmlwidgets_1.5.4          
 [41] spatstat.geom_2.4-0         purrr_0.3.4                
 [43] ellipsis_0.3.2              dplyr_1.0.10               
 [45] backports_1.4.1             annotate_1.75.0            
 [47] biomaRt_2.53.2              deldir_1.0-6               
 [49] sparseMatrixStats_1.9.0     vctrs_0.4.1                
 [51] ROCR_1.0-11                 abind_1.4-5                
 [53] cachem_1.0.6                withr_2.5.0                
 [55] grr_0.9.5                   ggforce_0.3.4              
 [57] progressr_0.11.0            checkmate_2.1.0            
 [59] sctransform_0.3.5           GenomicAlignments_1.33.1   
 [61] prettyunits_1.1.1           goftest_1.2-3              
 [63] cluster_2.1.4               lazyeval_0.2.2             
 [65] seqLogo_1.63.0              crayon_1.5.1               
 [67] hdf5r_1.3.6                 pkgconfig_2.0.3            
 [69] tweenr_2.0.2                nlme_3.1-159               
 [71] ProtGenerics_1.29.0         nnet_7.3-17                
 [73] pals_1.7                    rlang_1.0.5                
 [75] globals_0.16.1              lifecycle_1.0.2            
 [77] miniUI_0.1.1.1              filelock_1.0.2             
 [79] BiocFileCache_2.5.0         dichromat_2.0-0.1          
 [81] polyclip_1.10-0             lmtest_0.9-40              
 [83] Matrix.utils_0.9.8          zoo_1.8-11                 
 [85] base64enc_0.1-3             ggridges_0.5.3             
 [87] png_0.1-7                   viridisLite_0.4.1          
 [89] rjson_0.2.21                bitops_1.0-7               
 [91] R.oo_1.25.0                 KernSmooth_2.23-20         
 [93] blob_1.2.3                  stringr_1.4.1              
 [95] parallelly_1.32.1           spatstat.random_2.2-0      
 [97] readr_2.1.2                 jpeg_0.1-9                 
 [99] CNEr_1.33.0                 scales_1.2.1               
[101] memoise_2.0.1               magrittr_2.0.3             
[103] plyr_1.8.7                  ica_1.0-3                  
[105] zlibbioc_1.43.0             compiler_4.2.0             
[107] BiocIO_1.7.1                RColorBrewer_1.1-3         
[109] fitdistrplus_1.1-8          Rsamtools_2.13.4           
[111] cli_3.4.0                   listenv_0.8.0              
[113] patchwork_1.1.2             pbapply_1.5-0              
[115] htmlTable_2.4.1             Formula_1.2-4              
[117] MASS_7.3-58.1               mgcv_1.8-40                
[119] tidyselect_1.1.2            stringi_1.7.8              
[121] yaml_2.3.5                  latticeExtra_0.6-30        
[123] ggrepel_0.9.1               grid_4.2.0                 
[125] VariantAnnotation_1.43.3    fastmatch_1.1-3            
[127] tools_4.2.0                 future.apply_1.9.1         
[129] parallel_4.2.0              rstudioapi_0.14            
[131] TFMPvalue_0.0.8             foreign_0.8-82             
[133] gridExtra_2.3               farver_2.1.1               
[135] Rtsne_0.16                  ggraph_2.0.6               
[137] BiocManager_1.30.18         digest_0.6.29              
[139] rgeos_0.5-10                pracma_2.4.2               
[141] shiny_1.7.2                 motifmatchr_1.19.0         
[143] Rcpp_1.0.9                  later_1.3.0                
[145] RcppAnnoy_0.0.19            httr_1.4.4                 
[147] biovizBase_1.45.0           colorspace_2.0-3           
[149] XML_3.99-0.10               tensor_1.5                 
[151] reticulate_1.26             splines_4.2.0              
[153] uwot_0.1.14                 RcppRoll_0.3.0             
[155] spatstat.utils_2.3-1        graphlayouts_0.8.1         
[157] mapproj_1.2.8               plotly_4.10.0              
[159] xtable_1.8-4                jsonlite_1.8.0             
[161] poweRlaw_0.70.6             tidygraph_1.2.2            
[163] R6_2.5.1                    Hmisc_4.7-1                
[165] pillar_1.8.1                htmltools_0.5.3            
[167] mime_0.12                   glue_1.6.2                 
[169] fastmap_1.1.0               BiocParallel_1.31.12       
[171] codetools_0.2-18            maps_3.4.0                 
[173] utf8_1.2.2                  lattice_0.20-45            
[175] spatstat.sparse_2.1-1       tibble_3.1.8               
[177] curl_4.3.2                  leiden_0.4.3               
[179] gtools_3.9.3                GO.db_3.15.0               
[181] interp_1.1-3                survival_3.4-0             
[183] munsell_0.5.0               GenomeInfoDbData_1.2.8     
[185] reshape2_1.4.4              gtable_0.3.1               
[187] spatstat.core_2.4-4

What is the contract for the return value of these generics?

Broadly, there are two types of operations performed by these matrix summarisations:

  1. matrix-to-vector
  2. matrix-to-matrix

To take two examples from matrixStats:

  1. matrix-to-vector: val <- colMedians(x) results in length(val) == ncol(x)
  2. matrix-to-matrix: val <- colCummaxs(x) results in dim(val) == dim(x)

Particularly for matrix-to-matrix ops where the input is a disk-backed object, it may be desirable to be able to specify that the result should be realised on disk (or via some other backend) instead of as an ordinary matrix.

I see two options for the 'contract' of the generic and methods:

  1. Methods must always return an ordinary vector (matrix-to-vector) or matrix (matrix-to-matrix)
  2. Methods may return any suitable vector-like (matrix-to-vector) or matrix-like (matrix-to-matrix) object. E.g., the colCummaxs,DelayedMatrix-method might gain a BACKEND argument to specify what sort of object should be returned (with some sort of sensible default based on the class of the input).

I favour (2), although its flexibility makes for a somewhat 'loose' contract between the input and output.

BioConductor Submission

I believe the package is now almost ready for submission.

I ran checks with winbuilder and rhub, which were fine.
However, BiocCheck complained about the following things:

  1. NOTE: Consider adding these automatically suggested biocViews: DataImport
  2. NOTE: Consider adding a NEWS file, so your package news will be included in Bioconductor release announcements.
  3. Consider shorter lines; 473 lines (7%) are > 80 characters long.
  4. NOTE: Consider multiples of 4 spaces for line indents, 1066 lines(17%) are not.
  5. Cannot determine whether maintainer is subscribed to the bioc-devel mailing list

I would tend to ignore NOTE 1, 3, 4, and 5. About 2, I am not quite sure what to put into a NEWS for a new submission.

Two additional things, that we should think about:

  1. There is no vignette at the moment for this package. Does it makes sense for such a package to have one. And if yes, what would we put in there?
  2. @PeteHaitch, you are at the moment listed as the cre role in the DESCRIPTION. This would mean, that you would have to take care of the submission process, I believe. I can also take care of the submission, but am not sure what the appropriate role would then be.

Best, Constantin

Issue with matrixStats (>= 0.60.1)

Hi there

I have some errors in my CI/CD pipeline related to MatrixGenerics.

From what I see here, the package depends on matrixStats (>= 0.60.1): https://github.com/Bioconductor/MatrixGenerics/blob/master/DESCRIPTION#L24

http://bioconductor.org/packages/release/bioc/html/MatrixGenerics.html

This results in an error, as the version on CRAN is only 0.60.0

Indeed, the version on GitHub also doesn't go up to 0.60.1:
https://github.com/HenrikBengtsson/matrixStats/blob/develop/DESCRIPTION

If I understand the situation correctly, could you possibly fix this? I think matrixStats (>= 0.60.0) would solve this, no?
CC @HenrikBengtsson

Best, Evan

Questions on use of setGenericImplicit()

Martin Maechler urged for the use of implicit generics in the earlier email discussion (https://stat.ethz.ch/pipermail/bioc-devel/2017-November/012308.html). Admittedly, I feel like I'm fumbling around a bit here with an incomplete understanding of the methods package, but I have tried to implement this, e.g.,

setGeneric(
"rowMedians",
function(x, rows = NULL, cols = NULL, na.rm = FALSE, dim. = dim(x),
...) standardGeneric("rowMedians"),
signature = "x",
useAsDefault = function(x, rows = NULL, cols = NULL, na.rm = FALSE,
dim. = dim(x), ...) {
if (!requireNamespace("matrixStats", quietly = TRUE)) {
stop("'matrixStats' package required for matrix operations",
call. = FALSE)
}
matrixStats::rowMedians(x, rows = rows, cols = cols, na.rm = na.rm,
dim. = dim., ...)
})
setGenericImplicit("rowMedians")

The design pattern of setGeneric() followed by setGenericImplicit() is modelled on ddr; for example, https://github.com/vertica/ddR/blob/f6d7056fded5ae15385d5a16802b67116c30c188/ddR/R/ops.R#L203-L204.

Notably, this is different from that used by BiocGenerics. For example, https://github.com/Bioconductor/BiocGenerics/blob/2f85d3a0de8ab541e55d03ee6ea73d343349a7b8/R/matrix-summary.R#L6

Questions

So the first question is, have I got the use of setGeneric() and/or setGenericImplicit() correct?

Some other questions:

  • Should restore be TRUE (the default) or FALSE in setGenericImplicit()?
  • Should the appropriate matrixStats function (or function from other package, as needed) be used in useAsDefault argument of setGeneric()?
  • Is having matrixStats in Suggests and making its use conditional on it being available the right design?

Problem with the generic for 'rowLogSumExps()'

Hi,
I'm facing a problem that I think has to do with the entry in MatrixGenerics for rowLogSumExps(). See the following definition:

library(MatrixGenerics)
showMethods(rowLogSumExps, includeDefs=TRUE)
Function: rowLogSumExps (package MatrixGenerics)
lx="ANY"
function (lx, rows = NULL, cols = NULL, na.rm = FALSE, ..., useNames = NA) 
{
    MatrixGenerics:::.load_next_suggested_package_to_search(x)
    callGeneric()
}


lx="matrix_OR_array_OR_table_OR_numeric"
function (lx, rows = NULL, cols = NULL, na.rm = FALSE, ..., useNames = NA) 
{
    .local <- function (lx, rows = NULL, cols = NULL, na.rm = FALSE, 
        dim. = dim(lx), ..., useNames = NA) 
    {
        matrixStats::rowLogSumExps(lx, rows = rows, cols = cols, 
            na.rm = na.rm, dim. = dim., ..., useNames = useNames)
    }
    .local(lx, rows, cols, na.rm, ..., useNames = useNames)
}

The method for class ANY takes lx as argument, but the associated code tries to call a function with an non-existing object x, which should have been lx. The context in which I'm finding this is in a call to rowLogSumExps() that works interactively, but within a vignette I get this seemingly unrelated error (I mean unrelated to the code in the vignette):

Error in MatrixGenerics:::.load_next_suggested_package_to_search(x) : 
  Failed to find a rowMaxs() method for dgeMatrix objects.
Calls: <Anonymous> ... callGeneric -> eval -> eval -> rowMaxs -> rowMaxs -> <Anonymous>

Execution halted

Argument 'center' package tests

With the new 'develop' branch matrixStats version, I know get:

...
   1. ├─MatrixGenerics::colWeightedMads(...) test-api_compatibility.R:698:8
   2. └─MatrixGenerics::colWeightedMads(...)
   3.   └─matrixStats::colWeightedMads(...)
  
  ── ERROR (test-api_compatibility.R:1466:2): rowWeightedMads works  ─────────────
  Error: Argument 'center' should be of the same length as number of rows of 'x': 1 != 6
  Backtrace:1. ├─MatrixGenerics::rowWeightedMads(...) test-api_compatibility.R:1466:8
   2. └─MatrixGenerics::rowWeightedMads(...)
   3.   └─matrixStats::rowWeightedMads(...)
  
  ══ testthat results  ═══════════════════════════════════════════════════════════
  ERROR (test-api_compatibility.R:593:2): colSds works 
  ERROR (test-api_compatibility.R:678:2): colVars works 
  ERROR (test-api_compatibility.R:698:2): colWeightedMads works 
  ERROR (test-api_compatibility.R:1466:2): rowWeightedMads works 
  
  [ FAIL 4 | WARN 0 | SKIP 0 | PASS 306 ]
  Error: Test failures
  Execution halted

This is related to HenrikBengtsson/matrixStats#183. I've deprecated length(center) == 1 but for now it's still valid when arguments rows and cols are not specified. I think the above these use does the latter.

You could test with center <- rep(center, times = nrow(x) to avoid this. However, when you do, you must make sure that you test with a valid center estimate because otherwise the new sanity checks related to Issue #160 (switching from "alternative" to "primary" formula for the sample variance estimator).

'useNames = TRUE' is the new default in matrixStats v1.0.0

matrixStats v1.0.0 was just published on CRAN (HenrikBengtsson/matrixStats#232). The main change is that the old default useNames = NA is now deprecated and the new default useNames = TRUE.

I wonder if we should patch the current release version to use useNames = FALSE because that avoids deprecation warnings and won't change the behavior all of a sudden. And then with the next Bioconductor release change the default to useNames = TRUE

HEADS UP: New default for `ties.method` of {col,row}Ranks()

Background

matrixStats uses ties.method = "max" as the default for colRanks() and rowRanks() for legacy reasons, but we want eventually update to ties.method = "average" to align it with base::rank(), cf. HenrikBengtsson/matrixStats#142.

The process for this migration with be:

  1. Give a deprecation warning if ties.method is not explicitly specified (long time; several releases)
  2. Give a defunct error if ties.method is not explicitly specified (long time; several releases)
  3. Switch the new default to ties.method = "average"

This will have to take a long time in order to make sure end-users out there will notice this and update their code. I hope this will minimize the risk for existing code all of a sudden start producing different results.

Issue

MatrixGenerics gives an ERROR when I revdep check asserting !isTRUE(missing(ties.method)), cf. https://github.com/HenrikBengtsson/matrixStats/blob/feature/default-rank-ties.method/revdep/R_MATRIXSTATS_TIES_METHOD_MISSING%3Ddefunct/problems.md#matrixgenerics

Heads up: New `useNames` argument coming

Hi. We're gonna introduce a new argument useNames=NA/FALSE/TRUE in several matrixStats functions. We just added a 100%-backward compatible useNames=NA placeholder and rerun 347 revdep checks.

It turns out MatrixGenerics has package tests (e.g.

matrixStats_formals <- formals(matrixStats::rowProds)
MatrixGenerics_default_method_formals <- formals(MatrixGenerics:::.matrixStats_rowProds)
expect_identical(matrixStats_formals, MatrixGenerics_default_method_formals)
) that trigger errors on this. We get https://github.com/HenrikBengtsson/matrixStats/blob/feature/useNames%3DNA/revdep/problems.md#matrixgenerics, e.g.

 ERROR
Running the tests in ‘tests/testthat.R’ failed.
Last 50 lines of output:
  Length mismatch: comparison on first 6 components
  ── Failure (test-api_compatibility.R:1242:2): rowProds works  ──────────────────
  `matrixStats_formals` not identical to `MatrixGenerics_default_method_formals`.
  Length mismatch: comparison on first 6 components

Not sure how you want to deal with this. I guess you could just wait until matrixStats is updated on CRAN and fix it in Bioc release and devel when it breaks, or update these tests to be agile to the new useNames argument. FWIW, the plan is to roll a version with useNames=NA (100% backward compatible), and then further down the road make the new default useNames=TRUE.

Function only found on second attempt for sparse input

Hi,

I am trying to use a function from MatrixGenerics using the :: notation. However, it only works on the second attempt:

library(Matrix)
mat <- matrix(1:32, nrow = 8, ncol = 4)
sp_mat <- as(mat, "dgCMatrix")

showMethods(MatrixGenerics::colSums2)
#> Function: colSums2 (package MatrixGenerics)
#> x="ANY"
#> x="matrix_OR_array_OR_table_OR_numeric"
MatrixGenerics::colSums2(mat)
#> [1]  36 100 164 228
showMethods(MatrixGenerics::colSums2)
#> Function: colSums2 (package MatrixGenerics)
#> x="ANY"
#> x="matrix"
#>     (inherited from: x="matrix_OR_array_OR_table_OR_numeric")
#> x="matrix_OR_array_OR_table_OR_numeric"
MatrixGenerics::colSums2(sp_mat)
#> Error in get(as.character(FUN), mode = "function", envir = envir): object 'colSums2' of mode 'function' was not found
showMethods(MatrixGenerics::colSums2)
#> Function: colSums2 (package MatrixGenerics)
#> x="ANY"
#> x="matrix_OR_array_OR_table_OR_numeric"
#> x="xgCMatrix"
MatrixGenerics::colSums2(sp_mat)
#> [1]  36 100 164 228

Created on 2021-06-25 by the reprex package (v2.0.0)

I assume this is related to the whole discussion in #16 (comment). @hpages, do you know what is causing this and what we can do to fix this?

Best,
Constantin

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.