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

[jmh530]

On Tuesday, 13 March 2018 at 03:37:36 UTC, 9il wrote:
> [snip]
> 4. matrix[i] returns a Vec and increase ARC, matrix[i, j] 
> returns a content of the cell.
> 

I'm not 100% sold on matrix[i] returning a Vec instead of a 
1-dimensional matrix. R does something similar and you have to 
convert things back to a matrix for some computations more often 
than I'd like. If functions can easily take both Mat and Vec 
types in a relatively painless fashion, then I wouldn't have an 
issue with it.

> 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?)

> 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?

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

[1] Would it be seamless to add a Mat to a Diag? Also what 
happens to the api when you add 10 different matrix types and 
need to think about all the interactions.