# Matrix vs. AbstractMatrix
**URL:** https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912
**Category:** General Usage
**Tags:** sparse
**Created:** [June 20, 2024, 9:39am UTC](https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912 "2024-06-20T09:39:16Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@andreasvarga](https://discourse.julialang.org/u/andreasvarga)
#### Post date: [June 20, 2024, 9:39am UTC](https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912/1 "2024-06-20T09:39:16Z")
I am pondering to change the definition of the basic object `DescriptorStateSpace` used in the [DescriptorSystems package](https://github.com/andreasvarga/DescriptorSystems.jl) from
```julia
struct DescriptorStateSpace{T, ET <: ETYPE{T}} <: AbstractDescriptorStateSpace
A::Matrix{T}
E::ET
B::Matrix{T}
C::Matrix{T}
D::Matrix{T}
Ts::Float64
function DescriptorStateSpace{T}(A::Matrix{T}, E::ETYPE{T},
B::Matrix{T}, C::Matrix{T}, D::Matrix{T}, Ts::Real) where {T}
dss_validation(A, E, B, C, D, Ts)
new{T, typeof(E)}(A, E, B, C, D, Float64(Ts))
end
end
```
to
```julia
struct DescriptorStateSpace{T, ET <: ETYPE{T}} <: AbstractDescriptorStateSpace
A::AbstractMatrix{T}
E::ET
B::AbstractMatrix{T}
C::AbstractMatrix{T}
D::AbstractMatrix{T}
Ts::Float64
function DescriptorStateSpace{T}(A::AbstractMatrix{T}, E::ETYPE{T},
B::AbstractMatrix{T}, C::AbstractMatrix{T},
D::AbstractMatrix{T}, Ts::Real) where {T}
dss_validation(A, E, B, C, D, Ts)
new{T, typeof(E)}(A, E, B, C, D, Float64(Ts))
end
end
```
I must confess, I can not see all implications of such a change regarding the performance of the package (especially regarding compilation times).
With this change, all tests run without any problem, as before.
My motivation for this change is to allow the use of sparse matrices in descriptor system models. I need this functionality in the [PeriodicSystems](https://github.com/andreasvarga/PeriodicSystems.jl) package on which I am currently working (at this moment, simply as a container for lifted systems). I can of course manage without the above modification, by working directly with the system matrices, but the possibility of handling systems models with sparse matrix data is for me appealing for further extensions of the `DescriptorSystems` package.
_Note:_ This issue would be easy (i.e., without any modification) if the `SparseMatrixCSC` type would be a subtype of `Matrix`, but unfortunately it is not (it is only a subtype of `AbstractMatrix`).
I would appreciate any opinion on this issue.
---
### Author:  [@jishnub](https://discourse.julialang.org/u/jishnub)
#### Post date: [June 20, 2024, 9:51am UTC](https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912/2 "2024-06-20T09:51:30Z")
Typically, this would be done as
```julia
struct DescriptorStateSpace{T, ET <: ETYPE{T}, MT<:AbstractMatrix{T}} <: AbstractDescriptorStateSpace
A::MT
E::ET
B::MT
C::MT
D::MT
Ts::Float64
function DescriptorStateSpace{T}(A::MT, E::ETYPE{T},
B::MT, C::MT, D::MT, Ts::Real) where {T, MT<:AbstractMatrix{T}}
dss_validation(A, E, B, C, D, Ts)
new{T, typeof(E), MT}(A, E, B, C, D, Float64(Ts))
end
end
```
This would be equally efficient, as all the types are concrete, but it would be more general. The alternative as posed in the post would also work, but it might be less performant, as it would involve dynamically dispatching to the correct methods. Whether the difference in performance is a factor for actual problems remains to be seen, and may be checked by benchmarking.
---
### Author:  [@andreasvarga](https://discourse.julialang.org/u/andreasvarga)
#### Post date: [June 20, 2024, 10:15am UTC](https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912/3 "2024-06-20T10:15:09Z")
I am using
`const ETYPE{T} = Union{AbstractMatrix{T},UniformScaling{Bool}}`
to define `ETYPE{T}`. Is this consistent with the definition suggested by you?
Thanks in advance for your advice.
---
### Author:  [@jishnub](https://discourse.julialang.org/u/jishnub)
#### Post date: [June 20, 2024, 10:17am UTC](https://discourse.julialang.org/t/matrix-vs-abstractmatrix/115912/4 "2024-06-20T10:17:59Z")
Yes, this is fine, since the actual type `ET` that is used in the struct is a concrete subtype of `ETYPE{T}`.