pschur!(A::Vector{<:StridedMatrix}, S::Vector{Bool}, lr::Symbol) -> F::GeneralizedPeriodicSchur
Computes a generalized periodic Schur decomposition of a series of general square matrices
with left (`lr=:L`) or right (`lr=:R`) orientation.
Entries in `S` must be `false` for the corresponding entries in `A` which are effectively
inverted, and `true` for the rest. Currently `Sⱼ` must be `true` for the leftmost term.
I wonder if it would be possible to get rid of the restriction that
CurrentlySⱼmust betruefor the leftmost term.
I can imagine that removing this restriction is not trivial and can even lead to the redefinition of theGeneralizedPeriodicSchur object
and even to new computational approaches. However, for user's convenience this would be (in my opinion) very useful.
I implemented myself a similar interface routine to the SLICOT wrappers, without such a restriction (this was relatively easy, because the SLICOT wrapper to MB03BD supports exactly this). This allowed me, for example, to easily switch in the recently implemented periodic Riccati solvers from a quotient-product form to its inverse (where the Schur element is placed into a matrix which enters as an inverse factor).
I am watching with much interest your developments, because I am seriously concerned of the difficulties to generate correct binary libraries on a range of compilers and OSs for the SLICOT library. Although the SLICOT tools are very reliable and fast, I am pondering on the long range to get rid of SLICOT binding, provided alternative tools will be available in your package. I already implemented an alternative SLICOT-free interface for the continuous-time Riccati solvers, using the interface
The interface of
pschur!is currently defined asI wonder if it would be possible to get rid of the restriction that
CurrentlySⱼmust betruefor the leftmost term.I can imagine that removing this restriction is not trivial and can even lead to the redefinition of the
GeneralizedPeriodicSchurobject and even to new computational approaches. However, for user's convenience this would be (in my opinion) very useful.I implemented myself a similar interface routine to the SLICOT wrappers, without such a restriction (this was relatively easy, because the SLICOT wrapper to MB03BD supports exactly this). This allowed me, for example, to easily switch in the recently implemented periodic Riccati solvers from a quotient-product form to its inverse (where the Schur element is placed into a matrix which enters as an inverse factor).
I am watching with much interest your developments, because I am seriously concerned of the difficulties to generate correct binary libraries on a range of compilers and OSs for the SLICOT library. Although the SLICOT tools are very reliable and fast, I am pondering on the long range to get rid of SLICOT binding, provided alternative tools will be available in your package. I already implemented an alternative SLICOT-free interface for the continuous-time Riccati solvers, using the interface
pschur!(A::Vector{S<:StridedMatrix}, lr::Symbol=:R) -> F::PeriodicSchur