Question about abstract type interfaces


#1

Hi all, yet another newbie questions…
I want to create a new type as a subtype of an existing abstract type:
TinyBandedMatrix{T} <: AbstractSparseMatrix{T}
I wonder how to find details about the AbstractSparseMatrix interface that my new type must fullfill…


#2

Since AbstractSparseMatrix is a AbstractArray, start here:
https://docs.julialang.org/en/stable/manual/interfaces/#man-interface-array-1


#3

Thank you !
I guess I should start by AbstractArray and then figure out what additional functions should be available for AbstractSparseMatrix.
Sorry for this newbie question but the interface documentation should not be available for each abstract type ?
To me an abstract type may require an interface specification corresponding more or less to a concept in C++, traits in Rust or Haskell typeclass… Obviously I am still stuck in my OO way of thinking.


Displaying complex version of numeric type
#4

The documentation of interfaces has been improved a lot lately, but obviously more would still be better.

I’m not sure that sub-types always add to an interface. In this case a SparseMatrix is just a Matrix. Only the way things are stored in memory is different.


#5

Thank you. It is not clear to me that SparseMatrix is just a Matrix. I can imagine generic algorithms (e.g. matrix-vector product, show methods, solver like Gauss-Seidel) that may be common to different implementations (and different storage strategies) of sparse matrices. If someone develop a nice HTML show method for sparse matrices, it will probably be based on a common interface enabling iteration over non zero elts…


#6

Implementation and user API are precisely what Julia allows you to separate. Ideally, a sparse matrix is “just a matrix” in 90% of the cases from the user’s point of view, in the sense that knowing that it implements the interface is enough (for the remaining 10%, the user needs to care, eg choose to create such a matrix, etc).

At the same time, the developer would implement the right algorithm where it makes sense. The type hierarchy is a related design decision, and depends on how generic the relevant algorithms are. With careful design, only some functions need to be implemented for very specific subtypes, which can then be used by more general types, etc. Besides LinearAlgebra, the code related to <: AbstractRange is a nice example of this in Base.


#7

Totally OK. Using a matrix requires to know its interface. The same applies for someone who want to write a concrete type being a subtype of an AbstractSparseMatrix. Otherwise, why bother writing a nice documentation for AbstractArrays or AbstractRange ?