More systematically organize code handling interactions between various matrix types?

[Sacha0]

Code handling interactions between special matrix types (such as Diagonal), between annotation types (such as LowerTriangular), and between special matrix and annotation types exists distributed throughout base/linalg.

To illustrate, the name and comment at the top of base/linalg/special.jl indicates that that file contains code handling interactions between special matrix types. But that file also contains code handling interactions between special matrix and annotation types, for example convert(::Type{UnitLowerTriangular}, A::Diagonal). And immediately related methods, for example convert(::Type{LowerTriangular}, A::Diagonal), appear in base/linalg/diagonal.jl.

Would more systematically organizing code handling those interactions be worthwhile at this stage?

For example, would {introducing a file like base/linalg/special.jl but dedicated to handling interactions between special matrix and annotation types} and {segregrating corresponding code in that file} be a step forward? Would similarly {introducing a file equivalent to base/linalg/special.jl for annotation types} and {segregating corresponding code in that file} be a step forward?

Thoughts? Best!

[andreasnoack]

Yes. That would be great. It would be much clearer to have all the conversions in a single file after all the intra-special-matrix-type-methods have been defined.

If you want to take a stab on reorganizing the methods you might also want to think about the separation between the files for special matrix types and the files for factorizations. I think it would make sense to define all the special matrix types first and then define the factorization but that would require that e.g. all eigfact/vals function are moved out of the matrix type files and into the eigen.jl.

[stevengj]

See also #8240.