You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In other word, it seemed that the svd_atac$v and svd_atac$u were actually swapped, compared to RNA's svd$v and svd$u. When I check the input matrix, I found storage_order(mat_lsi_norm) was "row" while storage_order(mat_norm) was "col" as most scRNA-seq matrix in R would be.
Do you think BPCells::svds() should give u and v consistently regardless of storage_order, or should we just leave the users to check storage_order after calling it?
The text was updated successfully, but these errors were encountered:
Thanks for pointing this out -- definitely a bug in BPCells and not intended behavior. This should be fixed with the above commit.
The underlying cause here is that the C++ code treats everything as a column-major matrix, so row-major matrices need some special treatment to ensure conversion works properly
Hi, @bnprks. I followed the BPCells tutorials but computed SVD using
svds()
instead ofirlba()
. For example, in the RNA part:I got the same results as
irlba
:However, when it came to ATAC's
svd_atac
, I got this:In other word, it seemed that the
svd_atac$v
andsvd_atac$u
were actually swapped, compared to RNA'ssvd$v
andsvd$u
. When I check the input matrix, I foundstorage_order(mat_lsi_norm)
was"row"
whilestorage_order(mat_norm)
was"col"
as most scRNA-seq matrix in R would be.Do you think
BPCells::svds()
should giveu
andv
consistently regardless ofstorage_order
, or should we just leave the users to checkstorage_order
after calling it?The text was updated successfully, but these errors were encountered: