Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Is it time to consider unifying with pygraphblas?#196

jim22k started this conversation inIdeas
Discussion options

I expect GraphBLAS to become much more visible in the broader Python scene in the coming year or two. In the spirit of being Pythonic, there should preferably one (and only one) library for writing GraphBLAS code in Python. Readability counts.

@eriknw, I feel like you have been drifting ever closer to wanting an immediate execution mode and things likeA += expr to work. While there are things aboutpygraphblas that you don't like, it seems like some decisions on these fronts are growing on you.

I think we are within striking distance of closing the gap betweengrblas andpygraphblas. And while we started from a position of "purity", practicality now feels more urgent. Hence, I am willing to bend a little if we can get unity and and single community going forward, rather than a fragmented ecosystem.

I still like our use of delayedA.T,A.S, etc and theA(accum=..., mask=...) << expr syntax. I think that is actually quite elegant and readable. But the more we can move to an immediate-execution model, the less surprising things will be for new users.

Let's set aside time in our weekly meetings to brainstorm what this unification could look like, as well as the barriers needed to overcome.

You must be logged in to vote

Replies: 1 comment

Comment options

I'm open to this idea, but want to see more specifically what this might mean and what you have in mind. As I understand it, we had irreconcilable differences that motivated us to writegrblas, and we still do.

I'm not really interested in dropping any functionality or syntax already supported ingrblas. I could consider addingsome syntax frompygraphblas, and we do still need to add some SuiteSparse:GraphBLAS-specific features. Creating a common codebase for operators, datatypes, etc. forgrblas andpygraphblas to share is too much work and I'm not going to do it. These permeate too much ofgrblas codebase, and having full control of them has made my life so much easier. Having a larger common core also doesn't really help the "fragmented community" issue you raised.

Is the status quo so bad? I'm willing to listen and be convinced, but I need convincing.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Ideas
Labels
None yet
2 participants
@jim22k@eriknw

[8]ページ先頭

©2009-2025 Movatter.jp