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 memoryallocationsC = 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 goodopportunity 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.`