Designing a matrix library for D

[Mason McGill via Digitalmars-d]

On Monday, 23 June 2014 at 21:33:40 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> You are far from the first one to write a multidimensional 
> array library
> in D. Denis has already done this some time ago, and I have, 
> too.

I've seen Denis' library. It seems nice, but it's a lot more 
concrete that what the original post was discussing. Is yours 
online somewhere (for inspiration)?

> I've thought about this a lot, and my conclusion is that matrix 
> algebra
> is best left to a matrix-specific library wrapper that endows 
> matrix
> algebra properties on top of a generic multidimensional array 
> type. The
> main reason is that matrix algebra is rather peculiar to 
> matrices
> specifically, particularly the non-commutative matrix product, 
> and does
> not have very many useful usages outside of matrix algebra 
> itself; yet
> multidimensional arrays in general are useful in a wider scope.
>
> So in my mind, there are several components that are needed 
> here:
> - A generic multidimensional array, as a data container. This 
> can be a
>   set of diverse concrete types, e.g. to represent sparse 
> matrices,
>   etc.. No domain-specific operations are specified for these
>   containers; they are purely for storage and access only.
>
> - Specialized array types, like matrices which add matrix 
> algebra
>   semantics to the underlying multidimensional array storage 
> container
>   (e.g., matrix product), or tensor wrappers (endows tensor 
> product
>   semantics on the underlying container).
>
> - Algorithms: these take any multidimensional array, or 
> specialized
>   matrix type (depending on the purpose of each algorithm), and 
> operate
>   on them using a common multidimensional array API. They 
> should be as
>   generic as they can be, but no more, e.g., LU decomposition 
> algorithms
>   would take a matrix type rather than the general 
> multidimensional
>   array type, because it is specific to matrices, whereas 
> per-element
>   summation would take any general multidimensional array type, 
> since it
>   doesn't need matrix-specific properties. Similarly, subarray
>   operations should be able to work with any multidimensional 
> array
>   type, since it simply provides a restricted view on the 
> underlying
>   storage container, but doesn't depend on the implementational
>   specifics of the container itself.

Seems reasonable.

> I think the best solution would be a generic multidimensional 
> concept
> (analogous to the input range concept) that will fit all of our
> multidimensional array implementations. Algorithms that can 
> work with
> diverse ranks shouldn't care if the rank of a particular 
> concrete type
> is compile-time or runtime, for example. Let the algorithms be
> adaptable (up to practicality, of course -- if an algo can't 
> work or
> works very poorly with dynamic rank, then just add a
> constraint that
> requires static rank, for example), and the user can choose 
> which
> concrete type(s) best suits his needs.

One possible issue with dynamically-ranked grids is 
concept-testing. `isInputGrid!Collection` needs to check if 
`Collection` has a `size` property, and can be indexed with 
`size.length` indices. If this is to be done at compile-time, 
`size.length` needs to be constant.

> The concrete types can then be provided by a separate module, 
> and if we
> do it right, should be interoperable with each other.

Definitely an important design goal. You seem quite knowledgeable 
on this topic and I hope we can continue this conversation when 
my work on this is further along.