You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using this issue as a note for something that we should consider implementing in the future.
The generality that we have written our algorithms with is fantastic (e.g. allowing an observation bias c) but this does lead to some computational inefficiencies if used naively. For example, it's common for c to be zero and it is wasteful to store c as a dense array of zeros in this case. I don't think we need to make any modifications to our codebase to get around this, but it would be good to include an example showing how this waste can be avoided. I think the way to do this is to use Zeros from FillArrays.jl.
Another common case would be ones where have block sparse arrays. E.g. H could be zero in all dimensions except for the "position" ones. This could be handled via usual sparse matrices but I imagine a better, more comprehensive solution would be to have some sort of block sparse matrices.
This seems like less of a pre-solved problem. BlockArrays.jl seems somewhat related but enforces that all subarrays have the same type. Ideally we would want these to differ so you could have something like
Q = [
I Zeros(3, 3)
Zeros(3, 3) Zeros(3, 3)
]
I.e. we can still use the special I and Zeros as subarrays. CompressedSparseBlocks.jl also looks interesting but might not be the most suitable.
This would be a fantastic feature to showcase as it's fairly unique to the Julia ecosystem due to multiple dispatch.
The text was updated successfully, but these errors were encountered:
Using this issue as a note for something that we should consider implementing in the future.
The generality that we have written our algorithms with is fantastic (e.g. allowing an observation bias
c
) but this does lead to some computational inefficiencies if used naively. For example, it's common forc
to be zero and it is wasteful to storec
as a dense array of zeros in this case. I don't think we need to make any modifications to our codebase to get around this, but it would be good to include an example showing how this waste can be avoided. I think the way to do this is to useZeros
from FillArrays.jl.Another common case would be ones where have block sparse arrays. E.g.
H
could be zero in all dimensions except for the "position" ones. This could be handled via usual sparse matrices but I imagine a better, more comprehensive solution would be to have some sort of block sparse matrices.This seems like less of a pre-solved problem. BlockArrays.jl seems somewhat related but enforces that all subarrays have the same type. Ideally we would want these to differ so you could have something like
I.e. we can still use the special
I
andZeros
as subarrays. CompressedSparseBlocks.jl also looks interesting but might not be the most suitable.This would be a fantastic feature to showcase as it's fairly unique to the Julia ecosystem due to multiple dispatch.
The text was updated successfully, but these errors were encountered: