Consistency of return type of special matrices

[andreasnoack]

When I wrote functionality for the Triangular and Hermitian types, the general opinion seemed to be that the types should only be used for dispatch and that all methods should return a Matrix.

I have just noticed that methods for Diagonal return Diagonal e.g.

julia> inv(Diagonal(randn(4)))
4x4 Float64 Diagonal:
diag:  -1.54012  2.12275  2.08832  -0.976705

whereas

julia> inv(Triangular(triu(randn(4,4))))
4x4 Float64 Array:
 24.2769  -24.7589   31.9379    -2634.95  
  0.0       1.07824  -0.981735    107.485 
  0.0       0.0      -0.709239     54.6777
  0.0       0.0       0.0         -29.9744

Which solution should we go for?

[stevengj]

My feeling is that if the user is employing special matrix types for performance/memory reasons, then the user is entitled to receive those matrices back from operations that preserve special-matrix properties.

[andreasnoack]

I think I agree, but I forgot to mention that the original reason not to return special matrix types was that it would require many new methods to be written, i.e. ensure that all kinds of matrix multiplication is defined for the new types.

[vtjnash]

I haven't followed that discussion too closely, but is it possible to insert a superclass CompressedMatrix or MatrixLike (perhaps one of the existing ones already serves this purpose) and define generic convert methods on them for operations that call LAPACK? For many other operations, I imagine that indexing is easy to compute and offers roughly the same efficiency. I probably am not the best person to comment however.

[andreasnoack]

@vtjnash I think that is the point in JuliaLang/julia#2345. It has been discussed several times. I don't know if there are technical reasons why StridedArray is not yet an abstract type. I have tried to change the super class in jltypes.c but I cannot make it work.

[ViralBShah]

We should certainly try and resolve JuliaLang/julia#2345. Perhaps start a branch?

[stevengj]

It would be great to resolve JuliaLang/julia#2345, but special matrices like Triangular would still be different than a StridedMatrix. A StridedMatrix would denote any matrix with the same memory layout as a SubArray (and hence one which could be used directly with most BLAS/LAPACK routines).

A Triangular matrix would not be of this type. It's not clear to me how the proposed MatrixLike type would differ from AbstractMatrix, in fact. (More operations that work on AbstractMatrix would be great, of course.)

[ViralBShah]

Regarding the point in this issue, I agree with @stevengj 's suggestion to return the same special matrix type when possible. We can implement more operations on special matrices as we go along, and until then, users will have to manually convert to Matrix for operations that are not implemented.

Also, currently, we do try to implement as many operations on AbstractArray as possible with the current type hierarchy. I haven't reviewed this recently, but if you have specific cases in mind that can be made more generic, do file an issue. Fixing JuliaLang/julia#2345 should make it possible to make more of the array codebase generic.

[andreasnoack]

@stevengj I misunderstood the purpose of JuliaLang/julia#2345. Still, my feeling is that it would be useful to have a DenseAbstractArray. At least when you convert Integer (special) arrays to Float64 (special) arrays and hopefully also in other situations. For example the definition in matmul.jl line 65 could be changed to DenseAbstractArray and then cover the special matrices as well.

[stevengj]

How does a DenseAbstractArray differ from an AbstractArray? What methods could it support that a regular AbstractArray cannot?

It seems like only point of having a new abstract array class is if the new abstraction exposes more information about the storage or capabilities of the matrix, e.g. that it is laid out in memory with regular strides, or contiguously with transposed storage, or... I'm not sure what is being exposed in this case.

[andreasnoack]

AbstractArray covers distributed and sparse arrays so I think that a DenseAbstractArray do expose storage capabilities. In the example, a new array is constructed and it would not be clear which type it should be if the method at line 65 was defined for AbstractArray.

[stevengj]

What storage capabilities does a DenseAbstractArray have that AbstractArray does not? Line 65 of what file?

[JeffBezanson]

To me a DenseAbstractArray would be one that can use algorithms that touch every element, while for sparse arrays you'd try to touch only nonzeros.

[ViralBShah]

What if we just have AbstractArray, and in the case of AbstractSparseMatrix overload all those methods that in AbstractArray that touch all elements? That would avoid having one more type. That is essentially what we are doing already, and seems to work ok.

[JeffBezanson]

I agree we don't necessarily need the type, just saying what I thought it meant.

[andreasnoack]

@stevengj Line 65 of matmul.jl (I gave the reference first time). My idea was that DenseAbstractArray should be used for LAPACK calculations. It is possible that I don't understand what you mean by storage capabilities.