Do we need Mat, Vec, TMmat, Diag, Sym and other matrix types?

[9il]

On Tuesday, 13 March 2018 at 04:35:53 UTC, jmh530 wrote:
>> 5. Clever `=` expression based syntax. For example:
>>
>>    // performs CBLAS call of GEMM and does zero memory 
>> allocations
>>    C = alpha * A * B + beta * C;
>
> You might want to explain this in more detail. I saw expression 
> and my head went to expression templates, but that doesn't seem 
> to be what you're talking about (overloading opAssign?)

Expression templates plus overloading opAssign.

>> I have a lot of work for next months, but looking for a good 
>> opportunity to make Mat happen.
>>
>
> +1
>
> With respect to the title, the benefit of special matrix types 
> is when we can call functions (lapack or otherwise) that are 
> optimized for those types. If you want the best performance for 
> mir, then I think that's what it would take. I'm not sure how 
> much you've thought about this. For instance, I understand from 
> graphics libraries that if you're only working with a 
> particular size matrix (say 3x3), then you can generate faster 
> code than if you're working with general matrices.
>
> In addition, performance is not the only thing a new user to 
> mir would care about They likely would also care about 
> ease-of-use [1] and documentation. Hopefully these continue to 
> improve.
>
> What's TMMat?

TMat is a transposed matrix. Not sure for now if it would be 
required.

>
> Diag seems like it would be a special case of sparse matrices, 
> though diag is probably simpler to implement.

Diag should be an independent type. But not in the first release.

> [1] Would it be seamless to add a Mat to a Diag?

Mat C = M + D; // D - diagonal.
D += M; // Fails at compile time, but
D += M.diag; // pass

> Also what happens to the api when you add 10 different matrix 
> types and need to think about all the interactions.

User API would be simple. But it requires clever compile and 
runtime logic to do the best with expression templates.