https://github.com/evenex/linalg

I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff.

So I was using gl3n for awhile until I needed some 6x6s and threw together a syntax-sugary sort of wrapper over std.experimental.ndslice and cblas for matrix math.

You can slice submatrices, assign to them, and perform ops on them with other matrices or 2-dimensional array slices... though, for implementation-ish reasons, ops involving 2-d arrays are elementwise (you'll have to call the Matrix constructor to use matrix multiplication again).

It was built in kind of an ad-hoc way and I will be adding stuff to it as the need arises, so there's nothing there yet beyond the bare basics and you should expect bugs. All the matrices hold static arrays because I don't want to mess with reference problems right now. A matrix past a certain size will be more efficient to store as a dynamic array, of course. But, right now, I need this to make writing linear algebra code comfortable for myself rather than try to win at benchmarks.

Bugs/Pull/Feature requests welcome.

On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote:
> https://github.com/evenex/linalg
>
> I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff.
>
> So I was using gl3n for awhile until I needed some 6x6s and threw together a syntax-sugary sort of wrapper over std.experimental.ndslice and cblas for matrix math.
>
> You can slice submatrices, assign to them, and perform ops on them with other matrices or 2-dimensional array slices... though, for implementation-ish reasons, ops involving 2-d arrays are elementwise (you'll have to call the Matrix constructor to use matrix multiplication again).
>
> It was built in kind of an ad-hoc way and I will be adding stuff to it as the need arises, so there's nothing there yet beyond the bare basics and you should expect bugs. All the matrices hold static arrays because I don't want to mess with reference problems right now. A matrix past a certain size will be more efficient to store as a dynamic array, of course. But, right now, I need this to make writing linear algebra code comfortable for myself rather than try to win at benchmarks.
>
> Bugs/Pull/Feature requests welcome.

This is nice! I recently found myself having to make ad hoc lightweight matrix classes that wrap some blas functions. Making the dims template/compile-time params is an interesting choice, but I wonder if it is unduly limiting.

How does what you're doing compare to what's in https://github.com/DlangScience/scid/blob/master/source/scid/linalg.d ? While that project doesn't have a ton of manpower behind it, it does seem like it's actively maintained, and they have brought in a ton of the lapack/blas headers already. It would be nice, and I think do-able, to have a relatively complete and performant library for matrices/ndarrays, especially given the recent work on ndslice. (If there are plans or a roadmap for this sort of thing, I'd love to contribute, and it seems from this announcement that others are interested also.)

On Monday, 23 May 2016 at 18:10:40 UTC, Carl Vogel wrote:
> How does what you're doing compare to what's in https://github.com/DlangScience/scid/blob/master/source/scid/linalg.d ?

Basically, I have made a matrix structure and wrapped some basic arithmetic, while scid.linalg provides functions wrapping some heavier tasks (inversion, determinant, etc).
There appears to be no functional overlap, and I think what I will do is contribute any actual linalg routines I write back to scid.linalg, and then import it as a dependency to this package.
The stuff in my lib right now is way less careful wrt resources than scid.linalg and wouldn't serve as a general-purpose matrix wrapper. Maybe in enough iterations it will converge on something relatively performant.

On Monday, 23 May 2016 at 18:10:40 UTC, Carl Vogel wrote:
> Making the dims template/compile-time params is an interesting choice, but I wonder if it is unduly limiting.

Yeah, you are right. I mentioned dynamic-array-backed matrices as an efficiency thing in my first post but that would be a good way to solve this problem as well.

On Monday, 23 May 2016 at 20:11:22 UTC, Vlad Levenfeld wrote:
> ...

On first glance it looks like https://github.com/DlangScience/scid/blob/master/source/scid/matrix.d has most of what my matrix implementation is missing. Not sure how to put them together yet.

On Monday, 23 May 2016 at 20:27:54 UTC, Vlad Levenfeld wrote:
> On Monday, 23 May 2016 at 20:11:22 UTC, Vlad Levenfeld wrote:
>> ...
>
> On first glance it looks like https://github.com/DlangScience/scid/blob/master/source/scid/matrix.d has most of what my matrix implementation is missing. Not sure how to put them together yet.

There is also mir, which is working towards being a full replacement for blas:
https://github.com/libmir/mir

It is still under development, but I think the goal is to become the ultimate matrix library :)

On Monday, 23 May 2016 at 20:56:54 UTC, Edwin van Leeuwen wrote:
> There is also mir, which is working towards being a full replacement for blas:
> https://github.com/libmir/mir
>
> It is still under development, but I think the goal is to become the ultimate matrix library :)

I am sorely tempted to use mir's MatrixView as the backend for the matrix slicing but don't know what else I might need from cblas, so maybe this will come later (especially when I figure out, or someone explains, what the proper resource/reference handling should be, especially in the case of small matrices backed by static arrays or something).

Now I am thinking that the best way to orthogonalize (sorry) my efforts with respect to mir and scid.linalg is to use them as backend drivers, maintain this wrapper for the crowd that isn't as familiar with blas/lapack, or wants to write slightly more concise top-level code, and forward the relevant bug reports and pull requests to mir and scid.

On Monday, 23 May 2016 at 23:08:46 UTC, Vlad Levenfeld wrote:
> Now I am thinking that the best way to orthogonalize (sorry) my efforts with respect to mir and scid.linalg is to use them as backend drivers, maintain this wrapper for the crowd that isn't as familiar with blas/lapack, or wants to write slightly more concise top-level code, and forward the relevant bug reports and pull requests to mir and scid.

You might be interested in joining the gitter channel where the mir developers hang out:
https://gitter.im/libmir/public

On Tuesday, 24 May 2016 at 05:52:03 UTC, Edwin van Leeuwen wrote:
> You might be interested in joining the gitter channel where the mir developers hang out:
> https://gitter.im/libmir/public

Thanks!

On Tuesday, 24 May 2016 at 07:53:15 UTC, Vlad Levenfeld wrote:
> On Tuesday, 24 May 2016 at 05:52:03 UTC, Edwin van Leeuwen wrote:
>> You might be interested in joining the gitter channel where the mir developers hang out:
>> https://gitter.im/libmir/public
>
> Thanks!

Yes you are very welcome @gitter / mir!

Btw as said Ilya is working on full BLAS support.
There are a couple of issue floating around in the libmir issue tracker,
but probably the best one to track is this:

https://github.com/libmir/mir/issues/48

On Monday, 23 May 2016 at 07:28:20 UTC, Vlad Levenfeld wrote:
> https://github.com/evenex/linalg
>
> I've some heard people (including me) asking about matrix libraries for D, and while there is gl3n it only goes to 4x4 matrices and was written before all the multidimensional indexing stuff.
>
> [...]

Generic matrix-matrix multiplication is available in Mir  version 0.16.0-beta2
http://docs.mir.dlang.io/latest/mir_glas_gemm.html
It should be compiled with recent LDC beta, and -mcpu=native flag.