Open Sacha0 opened 8 years ago
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
.
See also #8240.
Code handling interactions between special matrix types (such as
Diagonal
), between annotation types (such asLowerTriangular
), 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 exampleconvert(::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!