[ANN] GraphBLAS binding for Go

[Pascal Costanza]

Hi,

I am happy to announce a library that we have been working on at Intel.

It is a Go binding for the GraphBLAS C API that calls into the widely used SuiteSparse:GraphBLAS C library.

You can find the Go binding at forGraphBLASGo and some example algorithms at forLAGraphGo.

GraphBLAS is a specification for an API that defines standard building blocks for expressing graph algorithms in the language of linear algebra. It consists of data types for opaque representations of sparse matrices, vectors and scalars over the usual elementary types (Booloans, integers, floating point numbers), as well as user-defined element types. Operations on those data types include matrix-vector, vector-matrix, matrix-matrix multiplications, element-wise addition and multiplication, and so on. Apart from the usual integer and floating point addition and multiplication, client programs can use other arbitrary operators with these high-level operations, represented as monoids or semirings, to express a wide range of powerful algorithms.

SuiteSparse:GraphBLAS is a complete implementation of GraphBLAS in the C programming language. It is used heavily in production. For example, it is used as the underlying graph engine in FalkorDB (previously RedisGraph), and as the built-in sparse matrix multiply in MATLAB. Several bindings exist for SuiteSparse:GraphBLAS for Python, Julia, and PostgreSQL.

The forGraphBLASGo library is a binding that defines a Go API for GraphBLAS and the SuiteSparse:GraphBLAS extensions. It strives to adhere to Go programming style as much as possible. Most prominently, it uses type parameters that have been introduced in Go 1.18 to make the various GraphBLAS object types generic, for added type safety. Other supported Go features include: using multiple return values instead of reference parameters, and Go-style error handling.

We consider the forGraphBLASGo library as quite mature. However, we haven’t yet assigned the version number 1.0.0 to it yet. If you have any feedback or suggestions for improvement, please let us know.

The forLAGraphGo library is less mature and still work in progress.

Looking forward to hearing what you think about this library.

Thanks a lot,

Pascal

[Corin Lawson]

Fantastic work! I'm no authority on the subject of Go programming style but the CheckErrors and OK pattern seems very unusual. Can you tell me the reasons for that design choice?

[Costanza, Pascal]

On 25 Sep 2023, at 23:31, Corin Lawson <corin....@gmail.com> wrote:

Fantastic work! I'm no authority on the subject of Go programming style but the CheckErrors and OK pattern seems very unusual. Can you tell me the reasons for that design choice?

The CheckErrors and OK pattern is there to make error checking in Go less tedious.

The most important information is that it’s completely optional. Errors are still returned as usual in forGraphBLASGo, and you can still check them however you want, including manually. If you use CheckErrors/OK in some places, you don’t have to use them everywhere, not even in the same package or even the same function.

With that out of the way: The motivation for this was that I wanted to be close to the C versions of graph algorithms expressed in GraphBLAS. When you check GraphBLAS for C, you see that there errors are also returned as values from functions. And when you check LAGraph for C, you can see that they introduce a macro for abstracting away error checks. (There are actually multiple of those for slightly different purposes, sometimes called TRY and sometimes called OK.) The macro essentially checks if the error is not “ok”, and in that case returns from the surrounding function early with that error code (including some cleanup, because there is no defer in C, which is why there are multiple versions).

While translating the algorithms to Go using forGraphBLASGo, it was clear that manual checks are too tedious. I experimented with a few approaches, including some publicly documented ones, for example https://go.dev/blog/errors-are-values - but most of them didn’t fly here in my opinion.

The CheckErrors/OK approach gets me very close to how the algorithms are expressed in LAGraph. The approach is actually very simple. Here are the definitions:

type nopanic struct {
    wrapped error
}

func CheckErrors(err *error) {
    x := recover()
    if x == nil {
       return
    }
    if np, ok := x.(nopanic); ok {
       if *err == nil {
          *err = np.wrapped
       }
    } else {
       panic(x)
    }
}
func OK(err error) {
    if err == nil {
       return
    }
    panic(nopanic{err})
}
You use it like this
func example() (result ..., err error) {
    defer GrB.CheckErrors(&err)
    GrB.OK(aFunctionThatReturnsAnError())
    x, err := aFunctionWithMultipleReturnValues())
    GrB.OK(err)
    err = aFunctionThatRequiresMoreComplexErrorHandling())
    if err != nil {
	...
    }
    ... 

}

As you can see, there is nothing specific about forGraphBLASGo here, so maybe it’s even a useful approach in other contexts.

I hope this helps,

Pascal

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/731a3bf6-a4af-408d-9e4c-20d781bf73e0n%40googlegroups.com.

Intel Corporation nv/sa
Froissartstraat 95
1040 Etterbeek
RPR (Brussel) 0415.497.718.
Citibank, Brussels, account BE52 5701 0312 5509

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.