Closed andreasvarga closed 2 years ago
I was anticipating the Krylov-Schur extension where the operators may not even be materialized as matrices.
Secondly, the internal routines typically want specific Julia types for Hessenberg or quasi-triangular components so some disaggregation seemed inevitable.
Finally, if one's systems are stored as 3-dimensional, one can call the code with view
s into them, but going the other way would need a copy (double the memory) or an awkward data structure.
Although I think I've seen mentions of varying dimensions in your papers, I don't have experience with the context where they are useful. I'd consider implementing them but don't have resources to do so in the near future.
Finally, if one's systems are stored as 3-dimensional, one can call the code with views into them, but going the other way would need a copy (double the memory) or an awkward data structure.
You mean something like
A = [view(a,:,:,i) for i in 1:size(a,3)]
?
Although I think I've seen mentions of varying dimensions in your papers, I don't have experience with the context where they are useful.
Time-varying state dimensions for linear periodic systems may be relevant in two contexts: minimal realization theory and order reduction.
Interestingly, to ensure the full generality of some computational algorithms for periodic systems, (e.g., periodic Kronecker-form based analysis), time-varying dimensions need to be considered!
For eigenvalue and periodic Schur form computation only the Hessenberg reduction would be essentially different, since the rest of computations can be performed on square submatrices.
What is the reason preferring the representation of periodic matrices via vectors of matrices over 3-dimensional arrays (as in the original SLICOT implementation)?
The vector of matrices based implementation would in principle allow working with time-varying dimensions. Do you intend to support at certain later time time-varying dimensions?