We do not have a good way of fully specifying abstract arrays without giving the full instance. For example, in DiffEq I would like the user to be able to pass whatever kind of Jacobian matrix type suits their needs. This would allow them to specify a banded matrix from BandedMatrices.jl, or a sparse matrix, etc. However, this is going to be part of the high level problem type which is something that I assume holds little memory and thus is simple to copy around (since it is in every other case). I would like to not hold instances of giant sparse matrices here.
The problem is that there is no way to re-construct that sparse matrix generically only from type information. If I know the instance, I can do:
to get a new cache of it, or I can do
to get a new cache with a different element type (which can be necessary for handling units). But, if I just have the type, I don't know how to re-create their sprasity pattern, and thus I am stuck with the problem type holding instances of these large objects in a very memory inefficient manner.
Now, the way this is supposed to work is that someone in this case uses the sparse constructor along with some array which specifies the non-zero elements. And for dense arrays one can pass a tuple for size. And for BandedMatrix ...? You can see that handling this using the given methods is not generic: I would have to setup each cache construction to handle every specific case the user can throw at me.
But it doesn't need to be like this. If instead we had an idea of "the abstract information which is required to re-build this type", then we could specify the way to construct any abstract type without providing instances. The simplest case would be dense arrays, where
struct DenseArrayConstructorInformation{T,N} <: AbstractArrayConstructorInformation
size::NTuple{T,N}
end
and thus (I am not wedded to these names at all)
construct(DenseArrayConstructorInformation((2,3),Float64)
is sufficient. But for sparse arrays, this could be different:
struct SparseArrayConstructorInformation{T,N,A} <: AbstractArrayConstructorInformation
size::NTuple{T,N}
nonzeros::A
end
where nonzeros can be any sufficiently nice collection (so this could be specified with a lazy array if this pattern is simple enough, making it take almost zero memory) and thus construct can be used on this. But then users can extend this. For example, the BandedMatrices.jl package could define the constructor information
struct BandedMatrioxConstructorInformation{T,N,A} <: AbstractArrayConstructorInformation
size::NTuple{T,N}
upper_size::Int
lower_size::Int
end
And then this can be used with construct. Each AbstractArray can have a much more memory effect "layout" information object from which it can be constructed, and thus this makes it easier to pass around ideas about AbstractArrays without passing and re-creating instances themselves.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4