Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSR/CSC Tracking issue #443

Open
1 of 15 tasks
hameerabbasi opened this issue Mar 16, 2021 · 10 comments
Open
1 of 15 tasks

CSR/CSC Tracking issue #443

hameerabbasi opened this issue Mar 16, 2021 · 10 comments
Labels
enhancement Indicates new feature requests

Comments

@hameerabbasi
Copy link
Collaborator

hameerabbasi commented Mar 16, 2021

cc @daletovar @ivirshup

  • Make attributes immutable, particularly compressed_axes.
  • Implement optimization changes for CSR/CSC:
    • Modify __array_function__
    • Modify elemwise
    • Modify _reduce_*
  • Benchmarks vs. scipy
    • Indexing
    • Broadcasting
    • Reductions
    • Array functions
  • Tests/benchmarks for
    • Indexing
    • Broadcasting
    • Reductions
    • Array functions
@hameerabbasi hameerabbasi added the enhancement Indicates new feature requests label Mar 16, 2021
@ivirshup
Copy link
Contributor

ivirshup commented Mar 18, 2021

It would also be good to figure out which attributes should be immutable, and for which classes this applies.

To me, information that is "part of the type" should be immutable. Now, because there isn't a super strong idea of "type of an array" in the ecosystem, I think this can be fuzzy. E.g. is the dtype of an array part of it's type? In a sense yes, since it controls what operations are allowed, but we can't isinstance(x, array[int]).

To me, it makes sense for arrays to be parametric on their number of dimensions and dtype. For sparse arrays with compressed axes, I think it makes sense for the compressed axis to be part of the type too.

@ivirshup
Copy link
Contributor

@GenevieveBuckley, @ryan-williams, potentially of interest to you. I think this is a key target for getting good sparse array support in dask -> having dask support in anndata.

@GenevieveBuckley
Copy link
Contributor

It's great to see you working on this @ivirshup

Was there any specific input you wanted from me, or just cc-ing for awareness?

Also, if you want to do some pair programming to work on dask + anndata, I'd be up for that. Let me know if that's something you'd find useful.

@hameerabbasi
Copy link
Collaborator Author

To me, it makes sense for arrays to be parametric on their number of dimensions and dtype. For sparse arrays with compressed axes, I think it makes sense for the compressed axis to be part of the type too.

+1, I agree with all of this.

I also added the points @ivirshup mentioned.

@AmPhIbIaN26
Copy link

I was looking to work on this issue, @hameerabbasi @GenevieveBuckley @ivirshup if you dont mind could you tell me a bit more about it since I am new to open source and sparse

@hameerabbasi
Copy link
Collaborator Author

@AmPhIbIaN26 Please don't tag everyone personally, it sends out a load of e-mails to people who may not want them

As for the answer to your question, look at our contributing page, and follow the links; read closely. If you have any specific questions, ask in the Gitter chat and not here.

@AmPhIbIaN26
Copy link

AmPhIbIaN26 commented Apr 8, 2021

Thanks and sorry for the inconvenience, ill follow up in glitter.

@ivirshup
Copy link
Contributor

Sorry for the late response on this! I'm quite busy with PhD/ life commitments at the moment but should hopefully have more time to work on this next month.


@GenevieveBuckley, mostly just letting you know! The pair programming could definitely be useful, I'll let you know when I have a chance to dip my toes back into dask.


@hameerabbasi a couple questions:

First, I'm trying to figure out the broadcasting, in particular result types. How does this sound for a promotion hierarchy:

input types output types
CSR CSR
CSC CSC
CSR,CSC CSR
T<:{CSC,CSR}, COO(1d) T

The main ideas here being:

  • CSR is preferred over CSC if we have to choose
    • This sorta fits the "C-ordered by default" numpy api
    • Alternatives include: this becomes COO, choose whichever type came first
  • 1d COO is treated similarly to dense arrays for finding the result type (no effect). That is, a one dimensional COO array won't cause the output to be COO.

Second, while trying some benchmarks for the stuff in my sparse_wrapper repo, I noticed sparsity structure can have a large effect on performance. I think it would be important to have a good sample of matrices to use in the benchmarks. There are quite a few collections of sparse matrices, and a number of benchmarking papers in this field I was looking at getting cases from. Do you have any preferences or recommendations here?

Benchmark dataset sources

Sources, strategies

Often take from the suite sparse collection:

@ivirshup
Copy link
Contributor

ivirshup commented May 5, 2021

I now have some time to work on this!

@hameerabbasi, do you think we could have a short call about this? Maybe early next week? In particular I'd like to get a sense of where this sits in the broader vision for the project, especially given the work on taco integration.

@hameerabbasi
Copy link
Collaborator Author

@ivirshup I've sent you a message on Gitter, let's chat there. 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Indicates new feature requests
Projects
None yet
Development

No branches or pull requests

4 participants