Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More generic interface for pschur! #10

Open
andreasvarga opened this issue Oct 3, 2022 · 0 comments
Open

More generic interface for pschur! #10

andreasvarga opened this issue Oct 3, 2022 · 0 comments

Comments

@andreasvarga
Copy link

The interface of pschur! is currently defined as

    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

Currently Sⱼmust betrue for the leftmost term.

I can imagine that removing this restriction is not trivial and can even lead to the redefinition of the GeneralizedPeriodicSchur 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

pschur!(A::Vector{S<:StridedMatrix}, lr::Symbol=:R) -> F::PeriodicSchur

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant