does gonum insist on row-major?

[Jason E. Aten]

I do alot of stats/numerical stuff but I haven't tried gonum until now.

Yesterday I went to port a bunch of C code that uses BLAS/LAPACK

into Go, and thought I'd try it (Gonum) out.  Now the logic is the original

code is very hairy, and does delicate operations like a bunch

of QR decompositions... in short, I don't want to mess with the

algorithm at all, I just want to port it to Go. The C original code runs fine against

OpenBLAS. Of course, being numeric code, it all assumes column-major

Fortran style matrices.

But when I tried to run the same logic on Gonum, I was hitting issues

left and right. At first I thought they were bugs in Gonum. But then

I realized, by default Gonum is assuming that your matrices will

be row-major (C-style).

There's almost zero documentation for gonum of these kinds of

 assumptions and even less about how to use

Gonum.... Like how do you switch between the Go and C BLAS implementation?

Not documented; that I can find. You would think this would be front and center. Ugh.

Anyway: somebody here probably knows-- does Gonum also support column-major

matrices?  In the Go BLAS, or in a cgo binding to OpenBLAS?

With Bewildered Thanks.

[Jason E. Aten]

ah... there is documentation, it is just buried...

https://pkg.go.dev/gonum.org/v1/gonum/mat#section-readme

"All matrices are stored in row-major format and users should consider this when expressing matrix arithmetic to ensure optimal performance."

Seems odd not to allow both; since this is usually very important for perf.

[Jan]

Not exactly what you asked, but something that you may consider: GoMLX. It's an accelerated ML and Math library that uses XLA --> it just-in-time compiles a computation graph to CPU/GPU (and hopefully soon TPU). It powers Jax/Tensorflow and is really fast (after the first execution).

Now, while pretty rich set of functionality, it's not a super-set of Gonum (it has some stuff not available in Gonum also). If anything is missing, but is supported by XLA, I would be happy to add. Plus it's well documented (see tutorial). Storage is row-major for 2d-tensors by default -- but internally it may reshuffle storage depending on optimization.

ps.: It's a biased suggestion (plus a bit of advertisement) because I created the project.

[Dan Kortschak]

On Sat, 2023-08-26 at 13:45 +0100, Jason E. Aten wrote:
> ah... there is documentation, it is just buried...
>
> https://pkg.go.dev/gonum.org/v1/gonum/mat#section-readme
>
> "All matrices are stored in row-major format and users should
> consider this when expressing matrix arithmetic to ensure optimal
> performance."
>
> Seems odd not to allow both; since this is usually very important for
> perf.

The original Cgo code did allow both. The maintenance burden or
providing both for the Go implementation would have been far too
onerous, so the column-major implementation option was remove from the
Cgo wrapper for parity.

I don't think the docs are buried; that is the first place people will
look in general.

FWIW The choice between rm and cm is difficult; all of Go is cm. All of
Fortran is cm (also any GPU code). We've had this discussion internally
and probably if we did it again, we might have chosen cm, but then we'd
get people complaining that they can't represent matrices in source
easily.

Dan

[Brian Candler]

Could you explain the comment "all of Go is cm"?

https://go.dev/play/p/tDJiSTqsiSC

[Dan Kortschak]

On Sat, 2023-08-26 at 07:28 -0700, Brian Candler wrote:
> Could you explain the comment "all of Go is cm"?
> https://go.dev/play/p/tDJiSTqsiSC
>

Sorry, that was a typo, should read "all of Go is rm" (what is there is
inconsistent with everything else I wrote).